W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2012

Re: [whatwg] Load events fired during onload handlers

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 31 Jul 2012 15:52:38 -0400
Message-ID: <50183786.3010106@mit.edu>
To: James Graham <jgraham@opera.com>
Cc: whatwg@whatwg.org
On 7/30/12 12:02 PM, James Graham wrote:
>> If desired, I can try to figure out exactly why there's only one load
>> event on the first iframe there.  Let me know.
> That would be really helpful.

OK, I looked into this.  There are two things going on:

1)  Gecko fires the load event on the <iframe> as part of the default 
action of the load event on the window inside that iframe.  I think the 
spec might actually call for it to fire async instead, though I haven't 
tested what other UAs do there.

2)  The code for firing the load event looks somewhat like this:

     if (!mEODForCurrentDocument) {
         mIsExecutingOnLoadHandler = true;
         // Fire onload here
         mIsExecutingOnLoadHandler = false;
         mEODForCurrentDocument = true;

and the handling for document.open() sets mEODForCurrentDocument to 
false.  Now what happens is we enter the above code for the normal load. 
  We fire the onload handler, which does the open()/write()/close() 
thing.  That tries to set mEODForCurrentDocument to false, but of course 
it's already false.  When close() happens, onload does NOT fire sync 
from the close() call, because there are still outstanding async tasks 
on the new document that block onload.  So we unwind the stack to the 
code above, and set mEODForCurrentDocument to true, and block any 
further firing of onload for this document until another open() call 

Fundamentally, that looks like a bug in the handling of 
mEODForCurrentDocument, really.

So if either that bug were fixed or item #1 above were changed, I think 
you'd get two load events here in Gecko right now.

Received on Tuesday, 31 July 2012 19:53:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:14 UTC