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
