Browsers, processes, cookies and session state

Opening the same web page in multiple browser tabs or windows can cause some serious problems if that page relies on cookies or session state. If you're lucky, the problem will be obvious to the user but it's quite possible that they'll be completely unaware of it until after they've corrupted some data.

The Problem

Imagine the user of a web application, viewing details of Object1. The user wants to compare Object1 with Object2 so opens the details of Object2 in a second window or tab. If the application is storing the "current object id" in session state or a cookie then this value will now correspond to Object2. The user then decides to modify Object1's details, so amends them on the page and saves the changes.

If the application is really badly coded then the save operation could update the record corresponding to the current object id (Object2) with the new details for Object1. Even if it updates the right record, the current id in session state is still wrong - if this id is used to select the data for the next page that the user visits then they will end up with both tabs/windows pointing at Object2.


The problem stems from the fact that multiple tabs and windows can be running in the same process.

Firefox uses the same process for multiple tabs and, by default, the same process for all windows, whether they are launched from Windows or from each other (Ctrl-N style).

IE6 managed it's own processes so you could never be entirely certain about when further processes would be created unless you forced the situation using the -new command line switch. The most common situation I've found is that Ctrl-N creates a window using the existing process, Javascript calls (e.g., use the existing process, but launching IE from Windows creates a new process.

IE7 has abandoned the -new switch, and seems to use a new process for each new window launched from Windows. All tabs within a window, however, run under one process, and spawning windows with Ctrl-N or Javascript commands seems to always re-use the existing process as well.

Cookies and Session State

Sharing a process isn't itself a bad thing. Time and resources can be saved by this approach, but unfortunately a browser's cookies are tied to it's process. If a page is displayed in two tabs or windows running in the same process, then the two instances of the page will share their cookies.

There are two types of cookie. Persistent cookies are saved to disk and kept until their expiry date. Persistent cookies will always be shared between multiple instances of the same page, regardless of whether the pages are running in the same browser process. If the page creates a persistent cookie called "ObjectID" then this will be stored in a file on disk and will be accessible to any other instance of that same page (unless you use a different browser application - IE and Firefox do not share cookies).

Session cookies, on the other hand, are kept in memory and are only available until the browser process ends. If two instances of a web application run in two separate processes then there will be two separate session cookies, but if the two instances are in the same process, then they will share the session cookie.

Furthermore, if the web application is relying on a session cookie to store a session id (the default setup for an ASP.NET web application is to store the ASP.NET_SessionId in a session cookie) then anything in session state will be shared between the two pages: if one of them updates session state then the other will be affected.


What this means for a developer is that it is quite possible that your application will have to cope with multiple copies of the same page running in the same process, sharing cookies. Ideally you should be able to have each page running independently of the others, regardless of them sharing a process.

Normally you can work around the problem by using viewstate. Small objects can be stored directly in viewstate but you shouldn't be sending anything too big down the line to the browser. If your object is more than a simple integer or short string then it will probably be better to generate a GUID and store that in viewstate, using the GUID to access a part of sessionstate which can be kept unique for that instance of the page, regardless of the process-sharing.

In the example we began with, the current object id could easily be stored in viewstate. If there was an object that needed to be persisted for some reason then it would probably be better off in session state, so the second technique would be better.

There are times, however, when viewstate doesn't work. In some situations (for example, setting up dynamically generated controls) the current object id may be required in Page_Init, when viewstate is not available. This was actually the situation which lead to us developing an HTA-based intranet (each instance of an HTA has it's own process, so cookies and sessions are never shared), but HTA is not an option for a normal website.

Probably the best solution, if you're using ASP.NET, is cookieless sessions. In this situation the ASP.NET session id is part of the URL, and is not shared between tabs or windows. This solution works well in the Page_Init situation, but leads to some very unwieldy URLs and has other drawbacks connected to security and absolute linking. It is also an application (or machine) setting, so cannot be used as a last resort only for those few pages that need Page_Init.


In general, viewstate is the perfect solution to the problem. Each instance of a page can keep track of its own state, with no interference from other instances.

When state information is required in Page_Init things get a little more complicated and cookieless sessions are definitely worth considering.


Test Code

A simple page incrementing a counter in session state can be used to demonstrate the problem. Launching new windows with CTRL-N in either browser will default to using the existing process, as will all tabs.

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

   Dim x As Integer

   If IsNothing(Session("test")) Then
      x = 1234
      x = CInt(Session("test")) + 1
   End If

   Session("test") = x

   Label1.Text = CInt(Session("test"))

End Sub
Published 06 November 2007 09:45 AM by jonsayce


# SimonS Blog on SQL Server Stuff said on 06 November, 2007 10:45 AM

If you've ever tried to undertake any aspect of web analytics you will know that browsers are generally

# Jon Sayce said on 26 November, 2007 03:26 PM

Running an HTA application alongside a browser can hide (or create) some nasty bugs if you're not opening

# leonc said on 07 December, 2007 11:43 PM

John - I'm not using the MS tools (ASP and so on) but I'm running into problems resulting from more recent version of MSIE *not* sharing cookie information. Our application pops up child data entry-oriented browser windows in several places and as cookies are not shared in the children windows, we're losing track of certain state-oriented info.

Do you know of a command line switch or setting we can instruct users to set in order to make child windows inherit the cookies or 'state' of the parent that begat them?

# jonsayce said on 16 December, 2007 11:56 PM


I don't know any way to force IE to share cookies that I would trust enough to rely on in an internet scenario.

Using generally opens the child window in the same process (i.e. sharing the cookie/state), but there's no guarantee of this in IE6 or IE7. IE7 seems much more likely to start new processes than IE6, so I suspect that's the root of your problem.

Using window.showModalDialog and showModelessDialog seem to reliably open the dialogs in the same process (when using IE), and I've used these before to share session between an application and a dialog, but only in an intranet system where I knew (and had control of) the user's setup, including the version of browser being used. Neither of these methods is W3C standard, and there's little support for them in browsers other than IE.

Without knowing more details of your app it's hard to say what the best solution would be. Using showModalDialog or showModeless dialog would probably work if you know everyone is using IE, but you might want to consider the alternatives. Would it be possible to make the data entry window part of the main application so you can avoid a dialog that needs session? Or could the dialog work without access to session, maybe getting the information it needs from a database? Perhaps you could pass the important information from session to the dialog in a different way, e.g. query string?

# LeonC said on 17 December, 2007 08:32 PM

Thanks John. Yes, this is as I suspected. Unfortunately, this system has about 2500 users around the state of CA and there's no way to dictate their platform. I think what I'll probably have to do is move to some kind of Ajax-based "window" that acts like a modal dialog box. I've not tried this but believe I have the tools to do something like this. Anyway, thanks for your input.

# jonsayce said on 26 March, 2008 09:10 AM

There was a comment on this post from someone called Ronnie in the last few days, but it seems to have been lost during the upgrade of the blog's software.

"We are having the same issue with Session sharing in muti pages in IE (New Window type)

Is there a way to disable the New Window (Or new tab)? base on an ID passed to my cookie?"

I don't think this is possible. The cookie is designed to store information about the user and, as far as I know, cannot be used to change the behaviour of the browser.

# How can I make two browser windows share the same ???session???? - Programmers Goodies said on 07 July, 2011 07:22 PM

Pingback from  How can I make two browser windows share the same ???session???? - Programmers Goodies

# Jquery Traversing - Afable said on 11 September, 2014 03:04 PM

Pingback from  Jquery Traversing - Afable

# Losing session state after close of a window opened with | Yorck Answers said on 09 December, 2014 10:16 PM

Pingback from  Losing session state after close of a window opened with | Yorck Answers