[whatwg] Should events be paused on detached iframes?

James May whatwg at fowlsmurf.net
Thu Aug 26 19:33:33 PDT 2010


On 27 August 2010 05:02, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/26/10 11:58 AM, James May wrote:
>
>> I thought I just suggested that?
>>
>> Everything works normally (as if it was still attached) until it is
>> reattached, when the situation is re-evaluated.
>>
>
> That could fall afoul of security checks that assume that an iframe with a
> non-null parent is in fact a subframe and that it's owner element is in the
> DOM.  I know Gecko certainly has such internally.
>
> Again, nothing insurmountable, but there's a bunch of code in Gecko that
> makes assumptions about when windows can and can't exist that would need
> auditing. I can't speak to the web compat aspects.
>
>
Could the iframe be hoisted to the top level of its parent browsing context?


>  In terms of resource consumption, I don't see how this would be any
>> different to any other kind of leak that web content can trigger.
>>
>
> I don't think that's an issue, though this does raise the question of when
> it's OK to gc the iframe.


When no references remain in either the DOM or script?

if an iframe<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element>is
removed<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#remove-an-element-from-a-document>from
a
Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document>and
is then subsequently garbage collected, this will likely mean (in the
absence of other references) that the child browsing
context<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#child-browsing-context>'s
WindowProxy<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#windowproxy>object
will become eligble for garbage collection, which will then lead to
that browsing context<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context>being
discarded<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#a-browsing-context-is-discarded>,
which will then lead to its
Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document>being
discarded<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#discard-a-document>also.
This happens without notice to any scripts running in that
Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document>;
for example, no unload events are fired (the "unload a
document<http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#unload-a-document>"
steps are not run).

Although I'm not sure why this is different from the regular steps.  (
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#garbage-collection-and-browsing-contexts
)

 (I think someone mentioned that iframes can be GC'd normally)
>>
>
> Can they, with your proposal?  It seems that with your proposal if you
> remove an iframe from the DOM and then forget about it then as long as
> there's any network activity in that iframe or anything else which might
> potentially trigger script it cannot be gced.  This seems like it would make
> it very easy to leak document after document...
>

So running scripts and network activity are GC roots?

-- James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100827/8665e1ee/attachment.htm>


More information about the whatwg mailing list