- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 31 Jul 2012 15:52:38 -0400
- 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 happens. 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. -Boris
Received on Tuesday, 31 July 2012 19:53:10 UTC