Preventing the context ribbon from appearing.

Selectively preventing the ‘inconvenient’ context ribbon.

Quite often I use list views to display summary data to the end users. This data often takes many forms from either a simple single list item displaying information about a site (I use this quite often in project sites.), to a full featured kpi display from multiple list items.

The common issue that I come across is the inconvenient behaviour of the context ribbon when the user clicks on the web part containing my list data. In this instance, because I’ve stripped out a lot of the default list behaviours in the xslt, the appearance of the context ribbon just serves to confuse the user, as well as highlighting my display web part in a big blue box that again serves no purpose.

Many blogs across the Internet will tell you that resolving this is easy thanks to the way JavaScript defines functions based on ‘last loaded wins’ theory, with this in mind we can just create blank functions for the key and mouse press events (WpClick() and WpKeyUp()) that come from list view web parts. This does indeed work very well except for when you have more than one list view web part on the page. If you use this method, then all of the web parts lose this functionality.

In my example project page, I have 2 list view web parts, the first is a project summary which uses a single list item to display the name of the project, a description, a link to the project manager and the current RAG status. My second web part is a standard list view of the projects document library for which I want to retain full SharePoint behaviour.


If we click on either web part, we get the usual blue highlight around the perimeter of the web part, and the context ribbon appears above.

The context ribbon appearing where we don't want it.

So whilst we can’t use the typically suggested method of overriding the functions WpClick() and WpKeyUp(), thankfully jQuery comes to our aid here with some simple DOM manipulation, we have simply to find the Id of our web part and then to remove the onmouseup and onkeyup events from it.

For these sites, the web parts won’t be changing position as the contributors don’t have the rights, so I don’t need to worry about the ID of the web parts changing and we can thus just use the ID generated by SharePoint when the web part was added to the page. If there was a likelihood of the ID changing, then we’d need some fancy jQuery trickery to find our web part ID.

Instead, I’m just going to use the Developer Toolbar in IE and use the “Select Element by Click” to select the web part and find the ID.


Else where on this page I already have some jQuery scripts collecting information from a list in the parent site using Ajax and the SharePoint web services, so I’ve called the following function from the $(document).Ready() delegate, passing in the ID of our web part.

function removeContextRibbonEvents(webPartID)
	if(webPartID.charAt(0) != "#")
		webPartID = "#" + webPartID;


With that code in place, clicking anywhere on the project information item doesn’t trigger the blue border or the context ribbon. Clicking on the documents list view however behaves as expected.

I hope this proves useful to you.


Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.