Bug 40047 – document.write is not synchronous when using the HTML5 parser

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Eric Seidel (no email)]

REGRESSION(60409): document.write is not synchronous when using the HTML5 parser

It's unclear from the spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/apis-in-html-documents.html#document.write()

But it seems to me that document.write() should wait until all parsing is "done" for the write before returning.

In the old parser this was not an issue, as it was not as aggressive about yielding.  The new HTML5 parser yields when waiting for script loads or for stylesheet loads.

http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#running-a-script
talks about queuing tasks on the task queue, but it doesn't really talk about the parser yielding.

The old parser never seems to wait for <script src=""> tags during parsing (in violation of HTML5) nor does it block inline <script> tags ever (which HTML5 says it should for style-sheets), so I think that's how it produces a synchronous document.write behavior.

[Eric Seidel (no email)]

http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-incdata

Talks about:

Spin the event loop until there is no style sheet blocking scripts and the script's "ready to be parser-executed" flag is set.

Which may be what we need to do when the parser is supposed to be synchronous (like for document.write).

[Eric Seidel (no email)]

I've tested and confirmed:  The old parser does not block document.write() for <script src> loads, however it won't actually process any contents of the write (or future writes) after the <script src> until that script has loaded.

I think the easiest way out of this is to remove the blocking of inline <script> tags on stylesheet loads.  To do so, we'd probably have to spin the event loop inside the parser like recommend by the HTML5 spec.  I don't really want to write that code (I am not even sure it's possible to spin the event loop from WebCore).  I think that's something we can deal with after we turn the HTML5 parser on as the default parser.

[Eric Seidel (no email)]

Created attachment 57632 [details]
Patch

[Adam Barth]

Comment on attachment 57632 [details]
Patch

WebCore/html/HTML5ScriptRunner.cpp:244
 +      //     m_parsingBlockingScript.element = script;
Commented out code!  :(

[Eric Seidel (no email)]

Created attachment 57633 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 57633 [details]
Patch for landing

Rejecting patch 57633 from commit-queue.

Failed to run "[u'/Users/eseidel/Projects/CommitQueue/WebKitTools/Scripts/svn-apply', u'--force']" exit_code: 1
Parsed 2 diffs from patch file(s).
patching file WebCore/ChangeLog
Hunk #1 succeeded at 1 with fuzz 3.
patching file WebCore/html/HTML5ScriptRunner.cpp
Hunk #2 FAILED at 238.
1 out of 2 hunks FAILED -- saving rejects to file WebCore/html/HTML5ScriptRunner.cpp.rej

Full output: http://webkit-commit-queue.appspot.com/results/2812104

[Henri Sivonen]

(In reply to comment #2)
> I think the easiest way out of this is to remove the blocking of inline <script> tags on stylesheet loads.

It seems to me that it would be sufficient to make document.written inline scripts not wait on network loads of any kind.

By inspection, it seems to me that Gecko isn't spec-compliant here. I intend to file a spec bug.

[Alexey Proskuryakov]

Since this isn't an issue in any production (or nightly) configuration, I've removed the REGRESSION prefix. Please let me know if this is a problem for your workflow.

[Eric Seidel (no email)]

Created attachment 57701 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 57701 [details]
Patch for landing

Clearing flags on attachment: 57701

Committed r60606: <http://trac.webkit.org/changeset/60606>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.