It seems that it isn't possible to create a second load event by doing a
document.open/document.write/document.close sequence from within an existing
Posted from: 2001:4c28:a030:30:ecfa:bf5f:96ca:7bec
User agent: Opera/9.80 (X11; Linux x86_64; U; Edition Next; en) Presto/2.10.289 Version/12.00
Can you elaborate? I don't understand what spec change is being requested here.
It seems that doing something that would cause further load events to fire from within the load handler (e.g. restarting / stopping the parser with document.open / document.write / document.close) doesn't in fact cause further load events to fire. If this was allowed the TC above would continue printing onload indefinitely, rather than once, as observed.
It is possible that the spec already prevents this in some way that I have missed. But if not, it should.
Oh, I see. You're saying that since document.open() restarts the parser, that you'll eventually go through the "stops parsing" logic, and that would fire 'load' and 'pagehide' and so forth again...
Does any of the other logic happen? What does document.readyState switch to? Do scripts run the way they do with a network parser? (e.g. does defer="" delay until document.close()?) Does DOMContentLoaded fire again? pageshow? Do appcache things get delayed again? Does window.print() get delayed again between open() and close()?
(In reply to comment #4)
> Does any of the other logic happen? What does document.readyState switch to? Do
> scripts run the way they do with a network parser? (e.g. does defer="" delay
> until document.close()?) Does DOMContentLoaded fire again? pageshow? Do
> appcache things get delayed again? Does window.print() get delayed again
> between open() and close()?
I expect document.open() to switch readyState back to "loading" and DOMContentLoaded to fire when the stream has been exhausted. It seems that the "load" event fires also as well as, in Gecko, "pageshow".
By code inspection, I would expect app cache selection to run again and defer scripts to be deferred again.
There should already be feedback about this in your pending mailboxes that store WHATWG e-mail.
It seems like the other events from The End still happen:
IRC discussion indicates that I was missing the point in comment 5.
This bug was cloned to create bug 18219 as part of operation convergence.
Updated test: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1799
So should I just silence the 'load' event in The End if the Document has the reload override flag set? (Or another one of the ways to detect document.open(), or maybe a specific flag just for this.)
A slightly more thorough investigation:
I've no idea what Opera is doing. Webkit and Opera don't fire the 'load 2' event. Gecko does, interestingly. The original example had nothing to do with this, though, it was about the iframe onload, not the page onload. Not sure why I got distracted down this road.
Based on further study, I think this is the right patch for this bug:
* in the iframe code that fires 'load', annotate the iframe's document so
that it knows we're in a 'load' event handler,
* in the document.open() code, set a flag to true if the aforementioned
annotation is set, and false otherwise,
* in the iframe code that fires 'load', don't fire 'load' if the
aforementioned flag is set.
Checked in as WHATWG revision r7713.
Check-in comment: Factor out a common step.
Checked in as WHATWG revision r7714.
Check-in comment: document.open() called from iframe.onload mutes future iframe 'load' events for that Document.
Checked in as WHATWG revision r7715.
Check-in comment: Rearrange for clarity.