Please read my blog's comment policy here.
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.
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, a bit off-topic here, regarding to inconsistent popup blocker behavior, any word on this:
@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.
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.
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.
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.
@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.
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!
@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...
I just realized this post title and URL are different, and I didn't notice it before, sorry :)
OK, now that the reason of refresh is well explained, is it still possible to eliminate it? Or it's not possible because IE want to recover the *original* popup, just like you've said, and not like Firefox or Chrome do it?
Also, I'm starting to figure out why I was kind of lost in this discussion, I just realized it later on :D.
In my mind, this is a workflow/sequence when a user click a link which trigger a popup:
My assumption of click operation workflow *):
#1 user click a link which trigger a popup on a website/page
#2 IE verifies that the link triggers popup but popup is currently blocked, it then DEFERS current click operation and show a notification bar to ask user whether user want to allow popup for current click operation or not (the consent, right?)
#3 if user click "Allow once" button, IE then set a flag for temporarily allowing popup in this page, then IE will continue the execution of current deferred click operation WITHOUT refreshing the website/page
#4 if user click otherwise (e.g.: close notification bar), then STOPS the execution of current click operation
Note that I initially thought step #2 was like an interception mechanism from IE to ask user response BEFORE continuing the execution of current click operation.
My confusion actually came from something I didn't understand in between step #2 and #3. As, if IE behave like that, I can't see a reason why a refresh is still needed. It would just be the same as adding the URL to exempt list, with a difference of adding it in the middle execution of a click operation using an interception mechanism and then simply continue its execution. But it seems I've misunderstood it :(
Thus, after reading your thorough explanations, also from Klimax, I just realized that's just not the case. This is my revised understanding:
Actual IE click operation workflow:
#2 IE verifies that the link triggers popup but popup is currently disabled, it simply STOPS the execution of current click operation
#3 even if "Allow once" button clicked, the execution of previous click operation won't be continued as it has been stopped. Instead IE set a flag and refresh the page
#4 after the website was refreshed, the popup shown AS IF it were triggered by INITIAL click operation, but that's not correct
So I initially saw the popup which triggered later on as if an illusion it were triggered by first click operation. But it seems that's not case.
Can you confirm that I have comprehended IE internal behavior correctly?
*) You might be curious why I thought like that. Perhaps I'm a dumb but I actually never read any explanation about how IE internally works in the case. It was purely coming from reverse-engineering IE behavior from a user standpoint. Does this actually documented somewhere? I must be missed it :D
How can you put a pop up blocker back on a site that you originally always allowed content to come through?
@Alenda: Manage the list inside IE's Tools > Internet Options > Privacy > Popup Blocker | Settings.
Firefox's design described: twitter.com/.../555037486724833280