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 18707 - It seems that if you document.write from within the load event and then reload the window, it is as if the insertion point was defined (i.e. it reloads the original content, not the document.written content). So something about the interaction of the inse
Summary: It seems that if you document.write from within the load event and then reloa...
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-08-27 17:22 UTC by contributor
Modified: 2012-11-27 04:43 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2012-08-27 17:22:30 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#the-end
Complete: http://www.whatwg.org/c#the-end

Comment:
It seems that if you document.write from within the load event and then reload
the window, it is as if the insertion point was defined (i.e. it reloads the
original content, not the document.written content). So something about the
interaction of the insertion point, the reload override flag and
document.write is wrong

Posted from: 85.229.223.104
User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.6.8; U; Edition Next; en) Presto/2.11.310 Version/12.50
Comment 1 James Graham 2012-08-28 14:52:00 UTC 
See the rendered view of http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1720

But note that WebKit and Gecko have different behaviours if you document.write *after* the load event; in WebKit/Opera reload reloads the original document, and in Gecko/IE it reloads the string:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1723 (rendered view)

There are also some incompatibilities in the number of history positions in various cases.
Comment 2 Ian 'Hixie' Hickson 2012-11-01 22:18:41 UTC 
In both cases (in Gecko) the content _is_ blown away, though:
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1885
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1884

Also worth considering:
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1886
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1887

The above is now specced (diff below).

The weird stuff though is:
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1888
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1889

Specifically, why is the nested onload="" not firing for 1888, in Gecko?

I've not tried to spec Gecko's behaviour in 1888. Reopen if you think I should.
Comment 3 contributor 2012-11-01 22:18:51 UTC 
Checked in as WHATWG revision r7497.
Check-in comment: Try to get a little closer to browsers.
http://html5.org/tools/web-apps-tracker?from=7496&to=7497
Comment 4 Boris Zbarsky 2012-11-27 04:43:27 UTC 
> Specifically, why is the nested onload="" not firing for 1888, in Gecko?

Because the open() happens during the firing of onload, so isn't treated as a new load, basically.  It's somewhat an artifact of how Gecko tracks whether it's in the middle of a load or not and the checks to prevent reentrant onload firing when onload does open()/close() pairs and other weird stuff like that.