I'm using SharePoint 2010 and Internet Explorer 9. (I have no choice in browser or versions -- policy dictates I use these until told otherwise)
I actually solved my problem, but I still don't understand why there was a problem, and I really want to understand why. The solution makes no sense to me. To paraphrase Douglas Adams, I speculate that if I knew exactly why this happened, I would know a lot more about the nature of the (SharePoint) Universe than I do now.
The problem I was having:
I have a page with many web parts. In a couple of content-editor webparts, I have javascript/jquery using the load() function to load in some list views, like this:
$("#ListofSubscribersPlaceHolder").load(SubscriberView+" .ms-listviewtable",function(responseTxt,status,xhr) {
if ( status == "error" ) alert( "Error: " + xhr.status + " " + xhr.statusText );
if (responseTxt.contains("no items to show")) {
$("#ListofSubscribersPlaceHolder").html("<p>No subscribers yet.</p>");
}
else {
// Remove the header row
$("#ListofSubscribersPlaceHolder table").find("tr").first().remove();
}
});
The list view includes the Edit icon and associated A-tag for each list item, with an onclick calling EditItemWithCheckoutAlert, which pops up the edit item form, and an href loading the edit item as a page instead of a pop-up.
When you visit the list view as a separate page, the Edit item works as you would expect, with a pop-up. But when you click on it in the web part, it follows the href to a web page instead of doing the pop-up form.
Other pop-ups that used the NewItem2 function in their onclick= worked fine. I set up alerts to show the A-tag after the page was fully rendered, and the onclick was definitely defined.
The solution I found:
Through digging and trial and error, I finally discovered that the problem went away (i.e. the popups work) if I removed the ms-listviewtable class from the table containing the link. So I added this line after the line that removes the header row:
$("#ListofSubscribersPlaceHolder table").removeClass("ms-listviewtable");
and now it works perfectly.
My Question:
I'm completely baffled as to why a class would prevent the onclick from working but let the href work. Looking at the stylesheets being pulled in, ms-listviewtable just defines borders and colors -- nothing fancy as far as I can tell.
In my search for a solution, I searched for how one might deliberately do such a thing. Aside from remonstrances that using css to modify behavior is wrong, there were 2 basic answers:
The pointer-events attribute. I checked that (with an alert of the A-tag's $(this).css("pointer-events")), and it is undefined. (Any other attributes I should check?)
Other suggestions involved covering the edit icon with an invisible unclickable layer, but wouldn't that also disable the href link? At any rate, I found no evidence that this was being done.
Any ideas what could be going on here?
Try it yourself
If you want to see for yourself, try adding this code:
<table class=ms-listviewtable>
<tbody><tr><td>TEST:</td>
<td>
<a onclick="EditItemWithCheckoutAlert(event,'http://www.google.com','0','','','/','','955');return false;" href="http://www.google.com"><IMG border=0 alt=Edit src="/_layouts/images/edititem.gif"></a>
</td></tr></tbody></table>
With class=ms-listviewtable
, I get a fresh page with google in it; without it, I get a pop-up on the current page (with an error saying it can't put that page in an iframe, but that's irrelevant: the point is that you get a popup, i.e. the onclick works).
If you can't reproduce it on SharePoint 2010, let me know, because then I can look for local anomalies.