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
Comments
Anonymous
May 24, 2011
Eric, a bit off-topic here, regarding to inconsistent popup blocker behavior, any word on this: connect.microsoft.com/.../inconsistent-behavior-of-pop-up-blocker-with-page-refreshAnonymous
May 24, 2011
@Maximilian: Your Connect issue isn't "off-topic"-- it's directly on-topic. I think it's a mistake to call the behavior "inconsistent" however, as these two options do entirely different things: The Allow Once/Allow All buttons says: "IE just blocked a popup I wanted to see. Refresh now in the hopes that it will be recreated". The User-Manually-Adds-Current-Site-to-the-Exempt-List says: "In the FUTURE, this site might show a popup. Just let that happen and don't block it." There's no point in refreshing the current page in this case, as it refers to some FUTURE event. Now, one point to mention because it may be confusing folks is that Chrome and Firefox only offer the second option (as a button). They are not written with the idea that you might want to recover the original popup. It's also worth reiterating that the "Refresh" behavior applies to more than just blocked popups; it applies to content blocking of many sorts, for the reasons I describe in the post.Anonymous
May 25, 2011
Sorry, I thought it's bit off-topic, Eric :D > "In the FUTURE, this site might show a popup. Just let that happen and don't block it." I agree that is for future event. That's what I have in mind as well. However, after adding (but not previously clicking "Allow once... button) a site to the exempt list while browsing a website, then clicking the same link the website that trigger popup, the page isn't being refreshed. IMO, that's NOT a FUTURE event and this is what I meant by inconsistent. See that the website isn't being navigated or changed whatsoever in its state. [EricLaw: The word after confers ordinality in time. Things that occur after some event are in the future of that event.] If I open the the website in new tab, that's a FUTURE event. But that's not the case. It's still in the same tab, the same IE window. Or perhaps I'm missing a definition of what future event is.Anonymous
May 25, 2011
A "future event" is something that happens at a later point in time. ("Time" is a concept which is scientifically associated with an increase in entropy and I'm sure Wikipedia has a nice writeup). In your scenario, when you LATER click the "same link [on] the website", you've done so at a LATER point in time. Hence, this event is in the FUTURE of when you changed your configuration setting, and hence no Refresh occurs.Anonymous
May 25, 2011
I should have been clearer in my post above: However, after adding a website to the exempt list (but not previously clicking Allow once/Allow all button) while browsing it (see that it's the same website that being browsed and added the exempt list; it's even in the same tab, the same IE window), then clicking the same link in it that trigger popup, then it is not being refreshed. If I take a different path (by clicking Allow one/Allow all) for the same website (that's not yet added to exempt list, or just remove it first from the list), it's being refreshed.Anonymous
May 25, 2011
@Maximilian: I think your confusion stems from the fact that the Allow once button is titled Allow once instead of what it should be titled, which is Darn it, IE, I didn't want you to block the popup you just blocked but it's too late to go back in time now, so please refresh this page and allow any subsequent popups in the hope that this will behave as if you didn't block the first popup. Whereas, when you adjust the Popup Blocker's Always Allow list configuration manually, you're saying: Hey, the past is the past. But in the future, anytime you see a popup coming from a site in this list, just allow it. K?thxbye.Anonymous
May 25, 2011
No, Eric. I'm simply asking for the reason why refresh is needed while I don't think it's necessary nor needed. [EricLaw]: Maximilian, I wrote a blog post on that very topic. Please scroll to the top of the page and read it. thanks!Anonymous
May 25, 2011
@Maximilian: It is NOT same. Allow* will appear when at present popup is blocked, while your manual adding is standalone. It is done asychronously of any other activity as far as browser is concerned. Refresh is atempt to recover popup,while your adding is future-proof with no recovery. (there is nothing to recover , nothing was blocked) So there is difference...Anonymous
May 27, 2011
The comment has been removedAnonymous
March 28, 2012
How can you put a pop up blocker back on a site that you originally always allowed content to come through?Anonymous
March 28, 2012
@Alenda: Manage the list inside IE's Tools > Internet Options > Privacy > Popup Blocker | Settings.Anonymous
January 13, 2015
Firefox's design described: twitter.com/.../555037486724833280