Last week we shipped SP2 RC1 for Windows XP. This is a Release Candidate and it is not intended to be used in production environments. However, those of you who love to test things can check it out here. Those of you who are merely interested in screen shots can find them here. Today I thought I would post some comments about some of the IE specific work in this release.
Pop-up blocker gets a lot of press, understandably. Pop-ups invariably top every list of customer complaints I have seen with regards to the browsing experiance. Everyone knows Pop-ups are annoying, but why, exactally, are they annoying? They are annoying because nine times out of ten the user does not want the pop-up and the pop-up happens automatically. When things happen automatically and those things are the wrong things users get annoyed and when users get annoyed they tend to make bad security decisions.
For example, a user navigates to a website that immediatly tries to install an active-x control. It is well established that most users will probably not read this dialog and will instead try to get rid of it as quickly as possible. But assume this time the user reads it and decides the control looks sketchy. The user clicks No on the dialog to abort the install. The dialog goes away, but it is immediately replaced by another dialog (a jscript alert()) directing the user to install the active-x control! The user clicks OK to dismiss the alert. This is immediatly followed by the same active-x install dialog the user just said no to. The user says no again. Rinse and repeat. The problem is during this whole time things you do not want to happen are happening automatically. And to add insult to injury the dialogs are modal, so you can do nothing else with the browser while they are there. You can not close it, or navigate away from this evil page. Most people eventually click yes just to get on with their lives. Often “ActiveX install” is replaced by “file download” in this scenario. This is a bad situation.
So one of the things we have tried very hard to do is put users back in control of what goes on in the browser. This is both a security thing and privacy thing. And, of course, like all things in Software Engineering, there are trade-offs. Typically security is gained at the expense of features and compatability. We have endevoured to balance these trade-offs to provide the smoothes experiance possible for the user.
The following information applies to the pre-release version of this service pack and is subject to change. Opinions expressed are purely my own, etc.
Users almost never want to see pop-ups. So we started by saying all pop-ups will be blocked. There are exceptions– brokerage sites use window.open() to display small windows with definitions of trading terms. E-tailors use window.open() to display small windows with sizing charts (clothing) and definitions of technical terms (computers, electronics, etc). To handle these exceptions we added code to detect user initiated actions– if the user clicks a link that wants to open a new window, we allow it to open one new window. The end result is no more cascading windows. Further more we imposed some restrictions on new windows that were not previously there. New windows must appear within the work area (as defined by the rcWork field of the MonitorInfo struct returned by GetMonitorInfo()). This means new windows must be completely visible to the user and must not cover shell app bars (such as the task bar, MSN dashboard, etc).
Tony can talk more to this specific area, but there are a few things I love about the work we did here. You can now say “Do not install this control and never ask me again.” You can disable controls that have been installed (as well as Browser Helper Objects) by using the Manage Add-ons feature. When navigating to a Web site that tries to automatically begin installation of an active-x control, the browser automatically blocks the install on the users behalf and instead provides modeless UI at the top of the screen informing the user that the installation was blocked. The user is then free to navigate the browser, close the browser, etc, or install the control by clicking on the modeless UI. No more endless looping of modal dialogs.
Downloads that are not initiated by the user by clicking on an element in the HTML are blocked, and instead of the download dialog modeless UI is shown at the top of the screen. The user can allow this download by clicking on the modeless UI or they can continue browsing the web.
Again, for the developers, you will be able to chose the classic modal UI or the new modeless UI when hosting the WebBrowser control. I am not sure if there is beta documentation for this yet or not though.
So for all of these things there may be an extra click or two involved when you do actually want the pop-up or download, but in the majority case IE will simply let you know that the Web page has requested something and IE has blocked it for the time being.
Questions? Comments? I will respond as best as I am able to the extent that I am able.