November 2007 - Posts

Why you shouldn't use window.open in HTA

Running an HTA application alongside a browser can hide (or create) some nasty bugs if you're not opening your windows correctly. An HTA application removes almost all of the useful development tools available in a browser window, so it's common for HTA-developers to also use normal browsers, but this requires extra care if you're opening new windows.

I mentioned last month that window.open is not trusted under HTA rules, so window.showModelessDialog or window.showModalDialog should be used instead. In addition, I posted earlier this month about browser windows sharing sessions.

In addition to the aesthetic issues, using window.open becomes a big issue if you try sharing session state between the application and the dialog. Normally you'd expect an error when firing up such a dialog from an HTA, as the session would not be available: window.open opens a standard browser window, unconnected to the HTA, running in a different process, so the dialog page cannot access the same session. At this point you'd normally switch to window.showModlessDialog (which opens a window in the same process as the HTA, so shares the session) and your session-based popup would be fine.

However, if you open the dialog from the HTA using window.open, whilst also running an instance of the application in a normal browser window, then the dialog can appear to work fine. This is because the dialog opens in IE, and IE can decide to use the same process for the dialog as used for the existing browser. Since the dialog and the browser share a process, they share session, so the dialog opens up with access to a session - just not the session that the HTA was expecting it to use.

This is the only time I've seen IE7 sharing a process between multiple windows - as I mentioned in my earlier post, it generally seems to create a process per window - but this just reinforces the importance of thinking about shared processes, and using the correct method to open extra windows from HTA apps.

Learning from your blog's referrals
Digging around in the referrals to a blog can be quite educational, especially for the blog's author.

The referrals list shows the pages from which readers have arrived - pages with links to your site. The list is created from an analysis of the HTTP requests received by the server. Each request has an HTTP header, which can include an optional field called Referer [sic], used by the requesting browser to tell the server what the previous page was.

The referrals list can be particularly interesting to the author because it shows the search criteria that people used when finding a post through a search engine - this is included in the querystring of the referring page. Having access to these criteria allows you to run the searches again (by following the link in the list), which gives you access to other people's search results. If they've used significantly different criteria to you then you may well unearth new pages related to the subject matter that you might have missed when running your own searches.

The only problem with this is that, if you discover something new, you may need to update your original post...
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.

Processes

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. window.open, window.show...) 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.

Options

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.

Conclusion

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
   Else
      x = CInt(Session("test")) + 1
   End If

   Session("test") = x

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

End Sub
Do you want your own database?

Following an excellent post by Jeff Atwood on Coding Horror, I've found some further reading about database change management, a topic I first posted on a few weeks ago, following a session at SQLBits.

Jeff's post is focussed on build scripts but one of the comments is by a guy called Mike Hadlow, who wrote about source-controlling databases a while back. A lot of what he suggests fits in with the change management strategy suggested at SQLBits, but he also recommends that each developer should work on their own database, in the same way that each developer works on their own copy of the code. When a particular change has been unit-tested satisfactorily then the scripts are updated into the repository and the other developers can "get latest" to update their own databases.

It's not something I've ever tried, but I quite like the idea of applying continuous integration ideas to database development.

The second article doesn't say much itself but has links to some more articles about source-control, and a list of useful tools.