[whatwg] Should events be paused on detached iframes?

Boris Zbarsky bzbarsky at MIT.EDU
Tue Jul 12 08:38:22 PDT 2011

On 6/13/11 8:09 PM, Ian Hickson wrote:
>> It's possible to switch these relevant checks to walk the ownerDocument
>> chain instead, say.  Then we need to audit all the callsites to make
>> sure this makes sense at them and figure out what to do for the ones
>> where it doesn't.  (For example, should window.alert on the window of an
>> iframe not in the DOM put up a dialog in a tab based on the
>> ownerDocument of the iframe?  Or not put one up at all?)
> It should put it up in the context of the top-level browsing context of
> the script that led to that point (the "first script"). This is the same
> as if someone in one tab calls another tab's script and that script calls
> alert().

Is that last what browsers actually do?  I'm pretty sure that's not what 
Gecko does...

> Note that only direct script invokations would work here. setTimeout,
> events, XHR callbacks, etc, don't run while the document is not active. (I
> had previously set that dispatchEvent() would work, but this is incorrect
> per the spec at the moment. My apologies.)


>> There are quite a few APIs that need to be thus audited if this
>> invariant is changed.
> Are there any I should look for off-hand?

You listed some above.

There are also issues in terms of network loads that are live when an 
iframe is removed from its document, whether network loads can _start_ 
in such a removed iframe, what the styling behavior, if any, is (e.g. 
how should media query matching work?), layout behavior, if any (what's 
the initial containing block size?).  What should happen if click() is 
called on anchors?  Or is that covered by the events thing above?

Basically, pretty much every single aspect of the platform's behavior 
needs to be sanity-checked in this context...

>> There are, yes.  There are also lots of edge cases that are otherwise
>> impossible that are introduced by allowing it; I'm a little curious as
>> to how compatible with each other the IE8 and Chrome implementations
>> are.
> I agree that this is an area that might well be minimally interoperable at
> the moment. That, of course, is the main reason to specify it. :-)

That's fine, but it seems like a v2 kind of feature to me.

I'm also a little saddened that there has been absolutely no feedback so 
far from the people who've been implementing this, even in cases when 
the current spec doesn't really cover behavior....  We're not going to 
get to interop that way.


More information about the whatwg mailing list