[whatwg] Load events fired during onload handlers

Boris Zbarsky bzbarsky at MIT.EDU
Tue Jul 31 12:52:38 PDT 2012

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.


More information about the whatwg mailing list