One behavior that seems to have inexplicably changed between IE8 and IE7 is the handling of session cookies. In IE7 (and 6) each browser instance and tab had it’s own session cookie and, as a result, session on the server. Not so in IE8! Every tab and browser instance (with some minor exceptions) now shares the same session cookie. When designing ASP.NET applications, this is something you need to be aware of. If you, for example, store an item currently being edited in session state and a user opens two browsers to edit two different entities, expect all kinds of strange results. If you want to test the behavior of a specific browser to see for yourself, visit this page. In my quick test, the latest version of Chrome behaves just like IE8.
So how do you make sure an application can support multiple browser windows? Well, there are a couple options, none of which is completely satisfying:
- Eliminate the use of Session State and switch to cookies, hidden form elements or some other client side mechanism.
- Enable cookiesless sessions (URL rewriting). Beware that this approach has some security implications as well as some practical effects on things like bookmarking and URL sharing.
- Train your users to select “New Session” from the File menu in IE8. Not exactly easy since the menus are hidden by default. If you enable them you’ll notice that you have both “New Window” and “New Session” as options. The latter will allow multiple browsers running different sessions.
The moral of the story is that if you decide to use session state, be sure to plan for users opening more than one browser window.
