I spent quite a bit of time yesterday tracking down a bug on a customised MySite. When you add document library list views to the page, and the view includes a column linked to an edit menu, the first one added to the page gets the wrong menu:   

instead of

This wouldn’t be too much of a problem in itself, except that the links don’t work, producing an error about “” being an invalid url.

   

After spending plenty of time eliminating all the possible custom code related causes (this is happening on a very heavily customised system), the problem turns out to be a conflict between the list view web part and the colleage tracker.

   

Context menus in SharePoint are created in JavaScript using a ContextInfo object. Document list web parts use a counter, so the first list view placed on the page will use a context object named ctx1.

   

Microsoft.SharePoint.Portal.WebControls.QueryResultBase, one of the base classes for the Colleague tracker, includes hardcoded javascript that uses ctx1 with settings that produce the non-working menu. Since QueryResultBase uses RegisterStartupScript rather than RegisterClientScriptBlock, the colleague tracker version (which comes from the base class and isn’t actually used) will always execute last, overwriting the settings from the document library view.

   

A couple of possible solutions come to mind:

   

  1. Extend ContactLinksMicroView (the internal name for colleage tracker), overriding the CreateCustomMenu method to return nothing, and use the customised webpart instead.

   

  1. Export the Document Library List View web part (via SharePoint Designer) and modify the list view xml to use something other than ctx1 to hold the menu settings.

   

Since we were already working with an exported webpart and dealing with escaped XSL mixed with CAML, JavaScript and HTML already, I tried option 2 first. Changing the references in the listview xml is easy enough, but after that there is still one reference to ctx1 left, which comes from the displaypattern of the hidden computed field _EditMenuTableStart. Changing that would get way too messy, so that option is out.

   

Extending the existing Colleague tracker web part works very well and turns out to be quite easy. It has the added advantage of being a modification to the web part that actually has the bug.