Consent and Browser Refreshes

Modern browser APIs like the GeoLocation API are designed to have an asynchronous consent experience, whereby the API simply will not undertake a privileged action until the user consents. Unfortunately, many browser features like popup windows and ActiveX controls were designed before privilege limitations were introduced, and many websites are designed with the expectation that the API will succeed immediately and synchronously.

When features like the Popup Blocker, Per-Site ActiveX, ActiveX Filtering, or Tracking Protection block an action requiring consent, Internet Explorer will refresh the web page if the user grants permission (e.g. by clicking an Unblock or Allow button). The problem is that if the browser prevents anything (e.g. an ActiveX control or popup) from loading at the expected time, JavaScript that might have depended upon its presence may fail (perhaps spectacularly) and not automatically recover when the user unblocks the content and that content eventually becomes available.

By refreshing the page after unblocking the content, Internet Explorer can limit the compatibility impact of the consent experience by ensuring that scripts and controls are loaded at their expected time when the page reloads. Unfortunately, this refresh can be disruptive, for instance, if you’ve entered data on the page, it may be lost when the browser refreshes.

Web Applications can be designed to avoid consent experiences and ensure that if APIs are blocked, a script error does not result.

For instance, the Outlook Web Access (OWA) team responds to popup blocking in a clever way. By default, popups are only permitted after a user-initiated action (click, Enter keypress, etc). OWA is designed such that most popups are the direct result of a user-initiated click and avoid the popup blocker automatically. However, some notifications may show at unexpected times and result in a block:

If OWA detects a popup was blocked (e.g. window.open returned null) then it shows the following HTML prompt.

When the user clicks on the Yes button, this click is treated as a user-initiated action, and the popup window will be permitted. If the second attempt to open the popup fails, the web application knows that the user is in a non-standard configuration (e.g. “Block all popups”) and notifies the user:

If the user clicks the Allow button rather than interacting with the OWA prompt, Internet Explorer will attempt to refresh. OWA has an OnBeforeUnload handler that warns the user that the Refresh will lose content:

If the user chooses to Stay on this page, then the page refresh is skipped, and the mail message is preserved.

In IE9, we’ve made an improvement so that the “Allow page to use popups” flag remains set on the current markup despite the lack of refresh, so the next time a popup is invoked, permission is granted based on the user’s consent. [Test Page]

As a best practice, web applications should expect that privileged APIs with consent experiences may not immediately succeed.

-Eric