IE in XP SP2 (Part 3): Web Site Compatibility
Microsoft cares a lot about application compatibility. So does the IE team, but we have an additional burden: web site compatibility. I think I can safely say that there are more web sites (intranet and internet) than there are applications, and many of them are built in a way that is closely tied to specific IE functionality.
While we really try to avoid making changes that affect compatibility, security is one thing that takes precedence. This means that with the large number of security fixes and features in XP SP2 some web sites will break. Between now and RTM things should get a little bit better, but we can't provide workarounds for every web site, and even when we can provide workaround the experience may not be as smooth as it was before.
In other words, if you're a web site developer or you have an application that hosts the web browser control you should strongly consider installing XP SP2 RC1 to test it out. Similarly, if your users are reporting bugs, don't discount them because they're running a pre-release version of XP SP2.
Below are some common types of problems that you should try to avoid.
As noted in earlier posts, IE no longer immediately launches the Authenticode dialog when it encounters an <OBJECT> tag. Instead, there is a more subtle non-modal piece of UI known as the Information Bar that lets the user know a control is present. This causes problems when web sites specifically rely on there being a modal dialog that blocks the web page. Example issues:
- Scripting an ActiveX control immediately after instantiating it, assuming the user will install it. (The user will get a script error, as they would if they clicked "No" pre-SP2.)
- Detecting that the ActiveX control wasn't successfully installed and navigating to an error page. In XP SP2 you'll navigate away from the page that gives the user the ability to install the control via. the modeless UI.
- Having the first instance of the ActiveX control after a form submit. In order for the user to install the control they now have to refresh the page, potentially doing a second submit. (Bonus points if the second form submit causes a duplicate purchase of an expensive product.)
Fortunately for web developers, ActiveX controls only need to be installed once. Make that experience work and you don't have much else to worry about here.
Pop-up Windows (non-user-initiated)
The best thing is to simply avoid showing pop-up windows. This shouldn't be news to anybody as there are literally dozens of pop-up blockers out there (in addition to being built into most major 3rd party browsers), but we've encountered plenty of sites that don't function well when pop-ups are blocked. Example issues:
- Redirecting when a pop-up is blocked.
- Instantiating an ActiveX control from a pop-up, especially if you close the window if it fails.
- Having one pop-up launch another pop-up in another domain. (Bonus points if the second pop-up attempts to install an ActiveX control or download a file, and the chain of pop-ups does a cascading close when the control is blocked.)
- One-time pop-ups that the user needs to see, but can't be replayed even after refreshing the page.
As noted in earlier posts, non-user-initiated downloads are blocked by default. This is something I haven't seen other browsers do and it may require a few download sites to adapt. Fortunately there's plenty of time before most users will have XP SP2. Example issues:
- Instead of launching the download directly, using the link to navigate to a page that kicks off the download using a timer.
- Creating a timeout, after which the server refuses to cough up the file. I've seen pages where I can start the download if I click the Information Bar within five seconds, but not after that.
- Launching a download from a pop-up window.
The Information Bar is a component of the web browser control and will not show up if you host mshtml directly, therefore some of the above items may be blocked outright with easy no end-user workaround. showModalDialog() and showModelessDialog() are where most web sites will encounter this.
MIME Type Handling
I'm not as familiar with this feature, I've run into problems caused by the security restrictions on a few web sites. The primary issue is servers that are misconfigured to send the type "text/plain" for binary file types such as streaming video or music.
Local Machine Zone Scripting
As mentioned in part 2, this is one of the most impactful changes. Again, I'm not intimately familiar with this feature, but if you're doing any kind of scripting from local HTML files that get launched in Internet Explorer (or shell Explorer) you should look into the documentation for XP SP2 RC1 for how to use "mark of the web" and other mitigations.
Of special note here are Explorer Bars and Desk Bands. We've seen several instances where these require the user to use the Information Bar to unblock script/content. In some cases the Information Bar is barely clickable due to the size.