[hsivonen]

It's quite different from innerHTML, since document.write inserts source characters to the character stream going into the parser, and there's no guarantee that all elements that get opened get closed. There's even no guarantee that the characters inserted don't constitute a partial tag. So document.write potentially affects the parsing of everything that comes after it.

For this to work, scripts have to appear to block the parser. However, it's desirable to start fetching external resources (images, scripts, etc.) that occur after the script that's blocking the parser. In Firefox, the scripts see the state of the world as if the parser was blocked, but in reality the parser continues in the background and keeps starting fetches for the external resources it finds and keeps building a queue of operations that need to be performed in order to build the DOM according to what was parsed. If the script doesn't call document.write or calls it in a way that closes all the elements that it opens, the operation queue that got built in the background is used. If the document.write is of the bad kind, the work that was done in the background is thrown away and the input stream is rewound. See https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_... for the details.

For added fun, document.write can write a script that calls document.write.

[Animats]

What a mess. To support a stupid HTML feature, the browser's parser has to be set up like a superscalar CPU, retirement unit and all. Hopefully the discard operation doesn't happen very often.

i86 CPUs have to do something like this if you store into code just ahead of execution. That was an optimization technique marginally useful in the 1980s. Today it's a performance hit. The CPU is happily looking ahead and decoding instructions, when one of the superscalar pipelines has a store into the instruction stream. The retirement unit catches the conflict between an instruction fetch on one stream and a store into the same location in another. The CPU stalls as instructions up to the changed instructions are committed. Then the CPU is flushed and cleared as for a page fault or context switch, and starts from the newly stored instruction.

Only x86 machines do this, for backwards compatibility with the DOS era. The same thing seems to have happened in the browser area.

(Prospective fetching should be disabled on devices where you pay for data traffic. Is it?)