[whatwg] Details on window.open

[Boris Zbarsky]

On 12/18/12 3:53 PM, Ian Hickson wrote:
> Per the spec, calls that would create a new browsing context are blocked
> unless called from the handler of a trusted 'click' event.

That's not web-compatible...

> I don't know if the spec is overly strict here; maybe it should also be
> possible on other trusted events e.g. mousedown or keydown?

Gecko's current behavior is as follows:

There are four possible states we can be in for popups: "Allowed" 
(allows popups), "Controlled" (allows popups, but only up to a global 
maximum number of popups opened from states other than "Allowed"), 
"Abused" (does not allow popups normally) and "Overridden" (does not 
allow popups normally).  If a site is white-listed in preferences to 
allow popups, then for that site "Controlled" is treated as "Allowed" 
and "Abused" is treated as "Controlled".

The default state is "Abused", I believe.

During handling of user input (which is NOT the same thing as an event 
being trusted, iirc; in particular there is some timer involved after an 
actual user input event was handled during which we treat things as 
being user input, because of sites doing window.open() from timeouts set 
from onclick), the popup state is set as follows:

click: "Allowed" if "click" is in the popup-allowed whitelist
select, change, input, keypress, keyup, keydown, mouseup, mousedown, 
dblclick, error, submit, reset: "Controlled" if the event name is in
    the popup-allowed whitelist

The default value of the whitelist is "change click dblclick mouseup 
reset submit", but can be modified by the user.

Furthermore, certain things propagate the popup state that was active at 
a previous point in time.  Specifically:

1)  Loading a javascript: URI will record the state that was active when 
the load started, and temporarily set that state during the async 
execution of the script.  So if your click handler sets a javascript: 
URI that does window.open(), that will work.

2)  Calling click() on an <input type="file"> will record the active 
popup state and test it when the task that would actually open the file 
dialog runs.  This is more or less an implementation detail, looks like; 
it's equivalent to just checking the state in click(), as long as you 
ignore the exact firing time of popup-blocked events.

3)  Submitting a form will record the popup state at the time the 
submission started.  When the asynchronous part of the submission 
happens (which is when a window would get opened if the form has an 
@target), this popup state is used to decide whether to allow the window 
to open.

I think this might be it, except for some code around plug-ins that I 
can't make sense of right now.

I strongly suggest talking to all UA vendors about how their popup 
blockers actually worked.  The Gecko setup used to be simpler, but we've 
had to add complications to it as we came across site compat issues...

> I haven't tried to spec it, because as far as I can tell, UAs could
> completely ignore it with no ill effects. If I'm wrong about this, then we
> should spec something.

I think on desktop you're somewhat wrong (e.g. it's possible to get site 
compat bugs where you open a window at the wrong size and users can't 
get to content)...  Most things other than the size bit can probably be 
ignored in that feature string, though.

-Boris