W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2006

[whatwg] What should document.write() do when called from setTimeout or event handlers?

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 5 Aug 2006 23:43:32 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0608052339340.5340@dhalsim.dreamhost.com>
On Tue, 1 Aug 2006, Stewart Brodie wrote:
> > 
> > IE seems to make those calls to document.write() simply blow away the 
> > document, as if the document was closed. Opera seems to do the same.
> 
> In other words, they treat it like being in an event handler context 
> where document.write is for replacing the entire document.  That seems 
> entirely reasonable to me.
> 
> Calling document.write() directly whilst in an event handler context 
> must blow the document away too, well, once you do document.close() that 
> is.

Well, once the document is closed (completed parsing), then sure, 
document.write() should blow away the document. But here we're talking 
about scripts that are executing while the document is being parsed.


> > Mozilla seems to make the document.write() calls insert text into the 
> > parser, as if they'd been called inline, with the result that the 
> > inserted text could appear pretty much anywhere. (It's actually a bit 
> > more complex than that -- it avoids inserting into tokens -- but 
> > that's a detail.)
> 
> I think we can do without Heisenberg-like effects from Mozilla :-)

I agree that this kind of race-condition effect is bad, but we can 
mitigate that by defining clear places where the tokeniser looks at 
pending document.write()n text, so this doesn't have to be quite as crazy 
as Mozilla's implementation.


> > I couldn't work out what Safari and MacIE do; they seem to delay the 
> > timeout somehow and then print to the end of the page.
> 
> Possibly they are preventing setTimeout/setInterval timeouts from firing 
> until the document is loaded?

I don't think so. They seem to only delay the document.write() calls.


> Finding a suitable definition for "until the document is loaded" remains 
> problematic.

Well, that's "when the load event fires". We'll have to document that in 
detail in due course.


> Easiest to disallow it like Safari/MacIE or behave like IE/Opera.  I 
> prefer the Safari way (it's what I've implemented, anyway :-)  Of 
> course, if you implement the Safari way, the Opera/IE behaviour is moot 
> because the situation never arises.

The Safari way has the problem that it means you can end up blocking once 
script while another script executes, which is a very bad situation to be 
in (theoretically, JS is not re-entrant except in well-defined cases).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 5 August 2006 16:43:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:28 UTC