Popup blocker should be "unlocked" after page click

UNCONFIRMED
Unassigned

Status

()

Core
General
--
enhancement
UNCONFIRMED
4 years ago
9 months ago

People

(Reporter: Cailin, Unassigned)

Tracking

({uiwanted})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
Many times when dealing with popups, JS programmers find themselves wanting to do validation on data, and THEN assuming the data is valid, opening a popup window. If this validation occurs asynchronously (perhaps the server is needed to do some of the validation) then the popup blocker is triggered, because technically the window is being opened not directly via user interaction. However, given the following psuedo code (using jquery syntax):

$('#element').click(function(){
    $.get('server/validation/page', function(data){
        if(data.valid){
            window.open(...);
        }
    }, "json");
});

we can easily see that this is not an abuse of popups, as it is still ultimately being triggered by user interaction.

So my proposal is this: Each time the user interacts with the page, that "unlocks" one window.open call, perhaps with a timeout, so the unlock isn't retained forever. This would allow for asynchronous tasks to create popups, while still ensuring that the popup blocker is doing its job. To limit the opportunities for abuse, the caveats would be that only one "unlock" can happen at a time, and possibly that unlocks expire after a certain amount of time.
Component: Untriaged → General
Product: Firefox → Core
We have something like this for setTimeout, with a 1000ms cap.

I suppose we could do something like that for XHR, with a similar cap....  The problem is that introduces nasty non-determinism: with a setTimeout you can base the cap on the arguments to setTimeout, so for a given call the window.open will either always succeed or always fail.  But for an XHR the cap might or might not be enough time for the roundtrip.

The problem with having a cap much higher than that is that users get very upset when the popup does not correlate with a user action from the _user_'s point of view.  Once they're more than about 1s apart in time, users on average feel that this is no longer a popup they asked for.
Keywords: uiwanted

Comment 2

9 months ago
In Chrome and other browsers, they allow popups where the async call stack originated from the user action.  This means that you can send a message from an iframe to the parent onclick and the parent page can open the popup.

We have a VPAID implementation where publishers require that their player handles the window opening.  In response to a click, we send the message to the parent window and then it's passed on to the video player.  The video player opens the link just fine in all browsers except Firefox.
You need to log in before you can comment on or make changes to this bug.