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.
An example of such a URL is below – the offending #serverfilter and the variables it delivers are bolded.
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).