Disable async main thread HTML parsing

Disable async main thread HTML parsing

This CL depends on CL: https://codereview.chromium.org/646913002/

This CL disables async main thread HTML parsing code path by:
- forcing HTMLParserOptions::useThreading to be true
- making all pumpTokenizer calls ForceSynchronous

HTMLDocumentParser has three parsing modes:
- Synchronous main thread parsing
- Asynchronous main thread parsing
- Asynchronous background thread parsing

Asynchronous main thread parsing is a historic feature before
asynchronous background parsing. Now all use cases that required
asynchronous main thread parsing are gone, we can disable
the code path so that we only have two parsing modes.

The HTMLParserOptions::useThreading had comment about where the
flag was used to force synchronous parsing behavior, but it is
obsolete as of now:
- The about:blank url itself does not use HTMLDocumentParser.
- javascript: urls use about:blank url, but synchronous behavior
  is not controlled by this useThreading flag, but call to
  pinToMainThread from DocumentLoader::replaceDocumentWhileExecutingJavaScriptURL.
- core/inspector/DOMPatchSupport also explicitly call
  pinToMainThread to force synchronous parsing.

This CL also removes the last asynchronous main thread parsing
case where:
- document.write caused recursive document.write via script, and
- the suspended document.write was resumed asynchronously.
However I think this behavior was a bug, as the suspended
document.write should have resumed synchronously.
To fix this, HTMLDocumentParser::resumeParsingAfterScriptExecution
is changed to resume parsing synchronously when background thread
doesn't exist.
This codepath is tested on fast/loader/external-script-URL-location.html

TEST=fast/loader/external-script-URL-location.html
BUG=421289
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=183572

[kouhei (in TOK), 2014-10-09 02:16:00]

kouhei@chromium.org changed reviewers:
+ eseidel@chromium.org

[kouhei (in TOK), 2014-10-09 02:16:09]

kouhei@chromium.org changed reviewers:
+ haraken@chromium.org

[kouhei (in TOK), 2014-10-09 02:18:11]

Would you take a look?

I will create follow-up CLs for removing the codes disabled in this CL.

[eseidel, 2014-10-09 16:29:37]

lgtm

Do you plan to remove useThreading in a follow-up?

[eseidel, 2014-10-09 16:30:23]

Actually, can you test your document.write change?  document.write is extremely
tricky and it's best to test it when we can.

[kouhei (in TOK), 2014-10-10 07:46:08]

> Do you plan to remove useThreading in a follow-up?
Yes. :)
After this lands, we can assume all main thread parsing is "ForceSynchronous"
mode, so a lot of complexity can be removed.

On 2014/10/09 16:30:23, eseidel wrote:
> Actually, can you test your document.write change?  document.write is
extremely
> tricky and it's best to test it when we can.

Recursive document.write code path is taken on
fast/loader/external-script-URL-location.html . I added it to CL description.

[kouhei (in TOK), 2014-10-10 07:47:45]

This patch exposed a loader bug. The layout test failures are fixed in separate
CL: https://codereview.chromium.org/646913002/

[kouhei (in TOK), 2014-10-11 07:34:38]

On 2014/10/10 07:47:45, kouhei wrote:
> This patch exposed a loader bug. The layout test failures are fixed in
separate
> CL: https://codereview.chromium.org/646913002/

The depending CL has landed and trybots look happy. Sending this to CQ.

[kouhei (in TOK), 2014-10-11 07:34:42]

The CQ bit was checked by kouhei@chromium.org

[commit-bot: I haz the power, 2014-10-11 07:35:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/644573002/40001

[commit-bot: I haz the power, 2014-10-11 07:38:47]

Committed patchset #3 (id:40001) as 183572