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.
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).
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.
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
Session("test") = x
Label1.Text = CInt(Session("test"))