Converting to HTA

An HTML Application (HTA) is a special HTML page which runs with the same security privileges as a normal window executable. It's displayed using the IE rendering engine but without any of the IE GUI or security model.

HTA systems are sometimes used to supply the UI on CDs and DVDs (e.g. the SQL Server 2005 install disk) and can also be used purely as a scripting host. One of the most interesting uses, however, is as the UI for an intranet application.

Intranet applications differ from general web application as they are trusted - the code on the intranet does not need to be subject to the same security as your average web page. Lifting these restrictions allows developers to write much more powerful applications, without having to work around the security model of the browser.

Another huge advantage of HTAs over normal IE is that you can control the processes: unless you start IE with the -New command line parameter, then IE is left to decide whether it needs a second process for a second browser. If it decides two browsers can share a process then they share sessions as well - cookies, session state, the works. Each HTA (and each instance of a particular HTA) runs in its own process, so nothing is shared.

Converting an existing web application to run as an HTA can be as simple as including the <application> tag in the start page and switching the extension of your page from ".html" to ".hta". Double-clicking the file will then launch an HTA window, as defined in your <application> tag. Once open, the HTA can be navigated to any page you want. The <application> tag has no effect on normal browsers - it is ignored.

In reality conversion is unlikely to be that simple. There are a number of things to bear in mind when converting a web application to be HTA-friendly:

• The most important point is that, since the browser security model is not being used, you should not let the user navigate outside your application. If you have links to external sites then these should open in new IE windows or frames (see below) which enforce the usual security model.

• Frames (including iFrames) are considered a danger in HTA systems as they can be used to show content which may not be as secure as the HTA system itself. Extra security restrictions are placed on the content of frames, for example the Javascript is not allowed to access it's parent frameset. If the content of a frame is safe (e.g. part of the same system) then frames can be declared as safe using the the application="yes" attribute. These frames then have full security privileges, as they are part of the trusted HTA. Viewing such HTML in a normal browser still works as the browser ignores the unknown attribute.

• HTAs do not get a status bar. For usability reasons it's best to give some indication that any slow requests are being handled (rather than just appearing to hang) so an Ajax-style div with a continuous progress indicator (an animated gif) can be useful. This can be displayed opaquely on the page's onbeforeunload event. One issue you may encounter with the onbeforeunload event is that it's triggered by any hyperlink with an href, even if the href is Javascript opening a new window. The solution (which is better practise anyway) is to use the onclick attribute of the anchor element for your Javascript, and just set the href to "#" or a non-Javascript page.

• The window.open command is not considered safe by HTA rules, so any new windows thrown up this way will have (at least in IE7) an address bar. If the content of the window is trusted then you can use window.showModelessDialog to open a window which is considered part of the trusted HTA.

• Any hyperlinks in pages opened using window.open will by default load their response into the same window. This is not true of windows opened as modeless (or indeed modal) dialogs: by default hyperlinks will open a new window to display their response, so target="_self" must be specified explicitly in the HTML of the dialog.