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.