There’s an area of application compatibility that may affect your app that you probably haven’t even thought about: session isolation. The effect of this is simple: how much (or how little) user/logon information is shared between two tabs open in IE8 compared to how much or how little was shared between two windows in IE6?
While I worked at Microsoft, I remember corporations asking Microsoft for hotfixes in IE7 because IE7 shared logon information between tabs differently than when the app was hosted in IE6, resulting in severe changes in workflow that required unwanted user retraining. Although Microsoft has taken some steps to alleviate that pain (see more on that below), with the introduction of IE8, IE9 and IE10, those technical considerations are continuing to evolve (alongside other concerns, like security).
Think of it this way: originally in IE6, each web page was its own window. There were no tabs, so each window assumed it was the only web browser open to a particular page. As security concerns grew, the IE team worked to lock down how much information one web page could share with another (especially across domains). Of course these security changes impacted compatibility (don’t they always), so the IE team added options to allow IE6 (and IE7, and IE8, and IE9…) to opt into or out of different security/compatibility settings depending on their needs. Look up on MSDN; there’s a whole slew of feature control keys that you can toggle depending on the version of IE you’re running.
Session state sharing & isolation too has evolved; in IE6, each window rightfully assumed it had the only view of a given web page (even if you had more than one window open to the same site). In essence, IE6 had session isolation with other IE6 windows. With the introduction of tabs in IE7, sessions sharing became common; the thought was that tabs open in the same window are likely related. In IE7, tabs within one window can share some session state (to the same domain). Give this a test: open a window to Hotmail in a tab in IE7, IE8 or IE9 and log in to your account. Then open a new tab in the same window and go to Hotmail. What do you see? You’re already logged in to your Hotmail account in that second tab. That’s session state sharing.
Great for usability… but your web applications may break because of it
While this behavior makes sense for every day users of IE accessing web sites with a single logon, it can break certain web applications when corporations evaluate IE8. They open a window to their web app and view some customer data and then they open a second window to the same app to view a different customer. The problem is, the view in the first tab also updates to that second customer! Unlike in IE6, where you could view multiple customers in multiple windows, in IE7 (and later) you have a problem where when you update any one customer view, all the other tabs update as well. You can see this if you try to open two different Twitter or Gmail accounts in two IE8 tabs today; as soon as you log on to the second account in the second tab, the first tab changes too.
This behavior can fundamentally break the way your application works, and the way your users use that applications. Fortunately, UniBrows offers a solution.
UniBrows can help manage IE session isolation the way you want it
For each profile in UniBrows, you can choose how you want session state information to be managed: shared (the default for UniBrows, and the default behavior in IE7+) or unique (like IE6; isolated). This screenshot shows the option you can toggle to change the behavior:
If you set a profile’s session mode to ‘Unique,’ then any tab opened in IE8 using this profile will use its own unique session identifier with the application instead of sharing it with other tabs. See for yourself: add a rule using the UniBrows configuration manager like so:
Set the session state setting to ‘Unique’ for the Default IE8 Standards Mode Profile (as in the first screenshot above). Save the settings locally and open a tab to Hotmail.com and log in. Then open a second tab to Hotmail: notice that in that second window, instead of viewing the inbox of the user from the tab you’ve already opened, you are presented with the Hotmail logon screen: essentially allowing you to log on to a different Hotmail account from the 2nd tab. That’s session state isolation in action, and that may be just the thing to get your older web application running like it worked under IE6.
It’s also interesting to note that our example did not use any IE6 technology from UniBrows. Session isolation is an issue that impacts modern web applications, and can be solved by UniBrows using one of the modern Internet Explorer engines – in the case, the IE8 engine. The same is true of dependencies on multiple versions of Java, as discussed on this blog last week.
IE8’s “NoMerge” option
You may have heard of IE8’s “-nomerge” option, which in some ways attempts to accomplish the same thing. Here’s an article to read if you’re not up to speed on this feature of IE8. Why isn’t this feature enough? There are a few reasons:
Ultimately, the UniBrows solution is superior because users don’t have to do anything differently: they can just browse from site to site in any tab in any window and the ‘right thing’ will happen. There’s no need for user retraining.
Summary
Session state sharing within a tabbed browser is often great for end-users, but a headache for corporate web applications. UniBrows allows you to customize this behavior on a per-profile basis to make it easy to manage how your internal web applications function.
The session state mode setting is available in versions of UniBrows 1.1 and later.
-Christopher
