[whatwg] Should events be paused on detached iframes?

[Boris Zbarsky]

On 8/26/10 10:33 PM, James May wrote:
> Could the iframe be hoisted to the top level of its parent browsing context?

Not sure what you mean.

> 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

It can't become garbage collected while the window inside it isn't, 
since the window inside it references the iframe (via frameElement).

>     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

I don't think it's reasonable to gc the <iframe> element while leaving 
the window inside alive due to it being referenced.  That introduces 
races where frameElement could suddenly become null at some point 
(possibly between two lines of the same script, or even partway through 
some operation; for example GC can happen, even multiple times, during a 
property get or set).  That would be pretty broken behavior.

> Although I'm not sure why this is different from the regular steps.

Presumably the only different thing is the lack of an unload event.

>     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?

Not running scripts.  Anything that might potentially run a script in 
the future.

You can think of it as gc roots, sure, and you can also claim that gc'ed 
systems never leak memory.  But is either necessarily useful?  The 
upshot is that random things that the web developer knows nothing about 
and doesn't care about can prevent the memory from being deallocated 
effectively forever from the web developer's point of view.  And worse 
yet, there's no obvious recourse (as in, no way to make sure the thing 
is garbage collected).  Any reasonable person would call that a memory 
leak in the browser, not in the site.  Just like a JS impl that never 
GCes until you navigate away from the page should be considered to have 
a memory leak.

-Boris