(In reply to bug 487949 comment #71) > (In reply to bug 487949 comment #63) > > No, there may still be unparsed data in the buffer chain if the caller did: > > document.write("<script></script>trailing data"); > > document.close(); > > > > Even without trailing data, posting a continue event ensures that onload is > > fired from the event loop rather than from within a script. > > This is a drive-by comment, and may not apply... Just posting an event may not > be enough here since modal dialogs etc process events, so a nested > document.write() that causes a continue event to be posted and then does > alert("foo") could process that event from within the script. It's unclear if this is a problem. Need to investigate if it is.

I'm pretty sure that after bug 503473, this isn't a problem for non-script-created parsers. However, in the case of script-created parsers, it might be necessary to deflect continue events if the parser is on the stack and have them flip a bit on the parser. Then, when the parser returns later, it should check the flag and re-post the event.

Thinking more about the script-created case: Only document.write() and document.close() feed data to the parser. They both tokenize to completion or until a script blocks. If they tokenize to completion, no continue event is needed. If a script blocks, nsContentSink posts a runnable for continuing when the script has run, no parser-level continue event is needed. If a nested event loop is created on </script>, there will be an nsContentSink-level continue runnable when the script has run, so that guarantees that the parse continues. If something other than </script> creates a nested event loop, the parser is running document.write() or document.close() to completion or a subsequent script, so there's no need for a continue event. Unless I'm missing something, it seems to me nsHtml5Parser-level continue events can be removed altogether.

Comment on attachment 410764 [details] [diff] [review] Remove continue event from nsHtml5Parser Glad to see this go!

a=beltzner to land on mozilla-central as this is pref'd off by default and so I'm happy to consider it NPOTB for now.

Thanks for r & a. Pushed: http://hg.mozilla.org/mozilla-central/rev/f4c2cd474968