- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 18 Dec 2012 17:38:17 -0800
- To: whatwg@lists.whatwg.org
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
Received on Wednesday, 19 December 2012 01:38:42 UTC