A client reported user grief in that when users clicked from static hyperlinks they had put on their SharePoint team site page Content Editor Web Part, which pointed to specific nodes on a Managed Metadata treeview menu, subsequent clicks of the browsers back button would not have the normal effect of returning to them from whence they came. In fact the back button in the browser really does nothing at all.

The reason is there is a # symbol at the tail end of the URL. The # symbol is traditionally used to denote anchor tags in HTML. In modern web applications it’s commonly used in AJAX techniques .

In the particular case of links to the nodes in the left-hand managed metadata menu, those links include a tag #serverfilter  with a bunch of parameters after that that tell the web browser to go to the specific node in the menu. Unfortunately, as the client discovered, Internet Explorer and some other browsers do not handle browser history normally when navigating via the # tag. Even though you are apparently loading new page content, the browser disagrees, because you are not actually loading an entire new web page – just a dynamic portion of Javascript that is displaying new content.

An example of such a URL is below – the offending #serverfilter and the variables it delivers are bolded.

https://sharepoint/teams/myTeam/MainLibrary/Forms/View.aspx?RootFolder=%2Fteams%2Fqms%2FMainLibrary&TreeField=Reference%5Fx0020%5FLevel&TreeValue=1522a33d%2D5b55%2D472f%2D970f%2Db09b9e804f3e#ServerFilter=FilterField1=Reference%5Fx0020%5FLevel-FilterValue1=106-FilterLookupId1=1-FilterOp1=In-TreeField=Reference%5Fx0020%5FLevel-TreeValue=1522a33d%2D5b55%2D472f%2D970f%2Db09b9e804f3e-OverrideScope=RecursiveAll-ProcessQStringToCAML=1

One of the biggest problems when using AJAX in web development has always been maintaining application state. In a Javascript heavy site (like SharePoint) one might want to do all sorts of things that alter the state of the user experience. For example, opening up modal dialogs (popups) over the page to request input from the user, etc. Because these state changes are occurring only with Javascript the browser is technically unaware of what is going on. If the user decides to hit the back button thinking they are just going back to before they opened a popup, they’ll be surprised when it takes them several steps backward to the last point where their browser actually made a full request. Similar issues occur when they refresh the page. The dynamic state is totally blown away and a new page request is made.

Since the basics of web navigation have always implied that a “new page” is what forms a single unit of web history, you’re not getting the back action as expected when direct linking to items in the Managed Metadata menu tree.  Unfortunately this is not a SharePoint-specific problem, it is endemic with lot’s of newer web applications online today from various vendors.

While I personally have coded workarounds for this type of problem in the past, it was for very specific, simple application scenarios (not like the huge complexity of SharePoint). In the case of out-of-the-box (mis)behavior like this I would advise simply that this unexpected back button behavior is the way it is and that users will have to adapt to selective back button history response (as they probably have on other online web applications).