Please read my blog's comment policy here.
Back in May of last year, I discussed changes we made in Internet Explorer 8 to make the browser’s session handling behavior more predictable. Specifically, we introduced a “New Session” item on the File menu—this menu item explicitly creates a new browser session which doesn’t share session information with the existing session. From the command line, you can open a new session using the -nomerge command line option.
We also changed other codepaths to ensure that no matter what other method you use to open a new IE window or tab, e.g.:
...the new window would run in the same browsing session as an existing window.
As I outlined in that post last year, pre-IE8 prior behavior was somewhat confusing to users who didn’t realize that they’d get a different number of active sessions depending on how they launched Internet Explorer. Beyond improving consistency, the new behavior also improves performance, and thanks to LCIE and crash recovery features, it doesn’t negatively impact reliability.
One downside to this change (or any change that’s visible to the user) is that there is a period of adjustment because some scenarios work slightly differently. When things change, the misunderstandings that users hold in their mental model of how the browser actually works are often spotlighted.
For this particular change, the most common complaint I’ve heard is “Something changed—IE8 won’t let me log out of a website anymore!?!”
When I ask for details, the scenario is always something like:
Now, users will try this exact set of steps on IE7 and at step #9 they will see that they are not logged in. In contrast, when they perform this set of steps in IE8, they will see that they are logged into the web mail site automatically.
In IE7, Step #1 creates [Session1, Session2, Session3]. Step #2 creates [Session4].
In IE8, Step #1 creates [Session1], with three windows sharing just one session. Step #2 creates a fourth window in [Session1].
So, when you get to Step #5 in IE7, the window is closed and [Session4] is destroyed, so the user is logged out. In IE8, Step #5 merely destroys one window in [Session1], leaving three more windows and [Session1] still alive. Thereafter, when the user opens a new window in Step #7, that new window is opened/merged into the existing [Session1].
What very few people realize is that both IE7 and IE8 work in the same way if a small change is made in the steps:
In this set of steps, both IE7 and IE8 create only one browser session, and closing any one window will not log the user out.
We’ve just learned that a browser session ends when you close the last browser window within a given browser session. So is that what you need to do in order to fully log out of a website?
There’s usually a better alternative: Click the site’s Logout button. When you do that, the site will typically expire your session on the server side, and send a command to delete your session cookie on the client side. You may still wish to close your browser windows (so someone can’t simply click “Back” to see the last pages you saw) but after you click Logout, the site should force you to log in again to make any changes or retrieve any new information.
A common follow-up question is: “What information is a part of a session?”
A site can clear its own session cookies by simply sending down new cookies of the same name (and path/domain) with an expiration time in the past. To clear its own sessionStorage, the proprietary clear method can be called. To clear HTTP Authentication and HTTPS client certificates, IE6 SP1 and later support the ClearAuthenticationCache command:
It’s worth mentioning that the ClearAuthenticationCache command clears ALL session cookies, Authentication, and Client Certificates for ALL sites running in the current session, so it’s definitely a command to execute judiciously lest you drive your site’s visitors crazy. Currently, no other major browser that supports the ClearAuthenticationCache command, although Chrome and Firefox have both acknowledged the problem and are discussing possible solutions.
Until next time,
 New windows will not be merged into an existing session if they are “incompatible”—e.g. we won’t merge sessions across UAC Integrity levels, and we won’t merge sessions unless options like InPrivate Browsing (-private) or No Addons Mode (-extoff) match the existing session.
Thanks for the pointer to http://code.google.com/p/chromium/issues/detail?id=5497. I'll try to get that implemented soon.
I was recently having trouble loging in to my online banking account. The usual symptom... could not login with IE8 (login page did nothing on submit) but I could with another browser.
At first I thought it was my overly long UA string, but reducing its length did not work.
I then fired up Fiddler to have a look at IE8's' requests and responses.
I then selected the Session Items in Fiddler and cleared them.
Behold.... I could then login to my bank account.
What is going on there?
Is fiddler using ClearAuthenticationCache?
If so surely secure bank login sites is the ideal case where we should use it.
@Rob: No, Fiddler doesn't call ClearAuthenticationCache (or any other URLMon APIs either).
If you use the "Clear Cache" button in Fiddler, it clears WinINET/IE's Temporary Internet Files cache, but it doesn't sound like that's what you did.
Even if Fiddler had called ClearAuthenticationCache, there's no explanation as to why that would fix the problem you describe. "Doesn't submit" problems are typically related to JScript running on the client.
Thanks Eric... I can't explain it. I just had a look again and all the external scripts are found and their domains are in my trusted sites list.... The Submit button is sus...
<input class="menubutton" onclick="this.disabled=true,this.form.submit();" type="submit" value="LOG ON"/>
I have worked for them in Portfolio management... I suspect their coders are in the dark and feed BS. A little more training is required.
FWIW: The use of the comma operator there is a bit odd-- a semicolon would be more typical.
blogs.msdn.com/.../session-management-within-internet-explorer-8-0.aspx discusses a registry key available to disable Frame Merging. There's a performance impact to using this, of course, since you'll end up with more frame processes.
I'm pretty interested on the subject because I have to maintain several ASP 3.0 applications, using Sessions that are being merged between tabs and windows.
I have only to support IE8.... I don't have to take care of any other browser.
The weakness of this solution is that the only way I have found to update my cookie on the server (when a same application is used from another tab) is to reload the page after new GUID generated and cookie value updated, but at this moment server-code has already been executed with wrong GUID read from the cookie....
I think I there's nothing else to do. I cannot see a way to read the SessionStorage.GUID, update cookie if needed and gurantee that meanwhile there is not server-code execution with old-cookie value. There's no way to update cookie neither to redirect or warn users on time.... any action done on client-side will be done after VBScript code.... :-S .... Am i wrong ?
I tested a https site which uses smart card, but I find when I open a new windows, it still need to select the cert and input the pin code. So why? Won't they merge the ssl session?
@EricTan: I might be mistaken, but I don't believe SChannel's client auth handles can be shared cross-process.
I notice that you said session Information contained https client certificates, a new window will share session in IE8. You mean the certificates used in SSL? If a new window or tab share the certificate, doesn't it mean that they share the ssl chamnel in order to use the same certificate?
@EricTan: Yes, IE8 is supposed to put new tabs/windows launched to the same host into the same process when a client certificate is in use in the original process. If you have a repro site showing that's not happening, can you please email me a URL?
Hi, EricLaw. I used fiddler to watch the process id of different tabs with same domain, such as vip.icbc.com.cn/.../index.jsp. I found that the process id was different. But the request of the some tab had the same process id. By the way, I used smart card to log to corporbank.icbc.com.cn, it 's odd that I had to select the certificate and input the pin most of the times when I opened a new window, but still have chance to log in without the process of selection and input. Can you exlain me it.
I'm sorry I am new here, so I don't know how to get you email from this site.
@Eric: I should have clarified-- the "leashing" behavior that keeps HTTPS sessions in the same process only occurs when one HTTPS page opens another HTTPS page using window.open(). If you navigate two independent tabs to the same HTTPS site, they aren't guaranteed to be kept in the same process.
Thanks for the very usefull entry. Just a question. Is there any way to perform a ClearAuthenticationCache just for the current domain?
is window.sessionStorage.clear() the way?
@Dani: No, there's no way to perform this function for just one site or domain. (It's a reasonable idea that we've considered, but not something that we've gotten many requests for). Clearing sessionStorage will not touch cookies, HTTPS client certs, HTTP Auth creds, or the TIF per-session cache.