This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17231 - 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 load event
Summary: It seems that it isn't possible to create a second load event by doing a docu...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-29 12:43 UTC by contributor
Modified: 2013-02-09 21:34 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2012-05-29 12:43:03 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#comments
Complete: http://www.whatwg.org/c#comments

Comment:
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
load event

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
Comment 1 James Graham 2012-05-29 12:48:49 UTC 
testcase:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1549
Comment 2 Ian 'Hixie' Hickson 2012-05-30 23:13:14 UTC 
Can you elaborate? I don't understand what spec change is being requested here.
Comment 3 James Graham 2012-05-31 08:59:42 UTC 
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.
Comment 4 Ian 'Hixie' Hickson 2012-05-31 17:43:15 UTC 
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()?
Comment 5 Henri Sivonen 2012-06-04 09:45:37 UTC 
(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()?

Per
http://hsivonen.iki.fi/test/moz/readystate/document-open.html
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.
Comment 6 James Graham 2012-06-05 12:12:45 UTC 
It seems like the other events from The End still happen:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1562
Comment 7 Henri Sivonen 2012-06-06 09:27:23 UTC 
IRC discussion indicates that I was missing the point in comment 5.
Comment 8 contributor 2012-07-18 17:43:36 UTC 
This bug was cloned to create bug 18219 as part of operation convergence.
Comment 9 Ian 'Hixie' Hickson 2012-09-26 03:52:53 UTC 
Updated test: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1799
Comment 10 Ian 'Hixie' Hickson 2012-09-26 03:56:48 UTC 
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.)
Comment 11 Ian 'Hixie' Hickson 2012-11-30 05:14:34 UTC 
A slightly more thorough investigation: 
   http://damowmow.com/playground/demos/onload/001.html

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.

See: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0420.html
Comment 12 contributor 2013-02-09 21:08:40 UTC 
Checked in as WHATWG revision r7713.
Check-in comment: Factor out a common step.
http://html5.org/tools/web-apps-tracker?from=7712&to=7713
Comment 13 contributor 2013-02-09 21:23:34 UTC 
Checked in as WHATWG revision r7714.
Check-in comment: document.open() called from iframe.onload mutes future iframe 'load' events for that Document.
http://html5.org/tools/web-apps-tracker?from=7713&to=7714
Comment 14 contributor 2013-02-09 21:26:13 UTC 
Checked in as WHATWG revision r7715.
Check-in comment: Rearrange for clarity.
http://html5.org/tools/web-apps-tracker?from=7714&to=7715