Flush pending text after every chunk of Tokens

Flush pending text after every chunk of Tokens

If you had a very slow loading page which would
hang in the middle of a text node, we would not
show the results of that text node until we
encountered the first token after that node.

This broke a web-based traceroute which used
http chunked encoding to keep the connection open
while it slowly piped the output of traceroute
over the http connection.
http://www.net.princeton.edu/cgi-bin/traceroute.pl?target=google.com&cmd=Go

This changes the behavior of our one test with a
gigantic text node by changing how the the text
is split.

I believe this also affected progressive loading of
text/plain documents.  I'm slightly surprised
no one complained.  I tested with:
http://norvig.com/big.txt
and we now progressively load that much better than
we do with dev channel chrome.

I'm not sure a good way to test this that won't be flaky.
If we encounter anything other than more text node
content in the http stream we'll immediately emit 
the pending text.  For now I'm going to presume
the one affected test is sufficient for coverage.

BUG=363974
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=172094

[abarth-chromium, 2014-04-18 21:51:02]

https://codereview.chromium.org/243823002/diff/1/Source/core/html/parser/HTML...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/243823002/diff/1/Source/core/html/parser/HTML...
Source/core/html/parser/HTMLDocumentParser.cpp:481: m_treeBuilder->flush();
Do we need this in the non-threaded case?  Maybe we should delete the
non-threaded case...

[esprehn, 2014-04-18 21:52:08]

Ideally we'd add a unit test or a http test for this, but I guess it's hard to
tell that we're hung inside the parser?

[eseidel, 2014-04-18 21:54:37]

We're not hung.  We've just buffered the in-progress text node and are refusing
to give it to you because you haven't hit another token yet.

I suspect his affects .txt document loads on the web, but for whatever reason no
one complained. :)

I could presumably make an http test which spit out some text and then hung and
then forced a dump before the load finished, but it didn't seem worth the
effort.

[eseidel, 2014-04-18 21:55:03]

I'm happy to look at removing the non-threaded case, I'm not aware of any
consumers.

[eseidel, 2014-04-18 22:04:50]

My current best guess for a direct test would involve a custom http resource
which spit out a script tag and then some text and then hung.  the script tag
would wait a timeout and then dump and the custom resource would hang for a
longer timeout.  Such would be flaky, but perhaps not too flaky that it would
still be worth testing.

[abarth-chromium, 2014-04-19 00:01:09]

LGTM

[eseidel, 2014-04-21 17:16:48]

The CQ bit was checked by eseidel@chromium.org

[commit-bot: I haz the power, 2014-04-21 17:16:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/eseidel@chromium.org/243823002/1

[commit-bot: I haz the power, 2014-04-21 17:53:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-21 17:53:39]

Try jobs failed on following builders:
  tryserver.blink on mac_blink_rel

[eseidel, 2014-04-21 19:38:52]

The CQ bit was checked by eseidel@chromium.org

[commit-bot: I haz the power, 2014-04-21 19:38:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/eseidel@chromium.org/243823002/20001

[commit-bot: I haz the power, 2014-04-21 20:21:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-21 20:21:37]

Try jobs failed on following builders:
  tryserver.blink on win_blink_rel

[eseidel, 2014-04-21 23:00:15]

The CQ bit was checked by eseidel@chromium.org

[commit-bot: I haz the power, 2014-04-21 23:00:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/eseidel@chromium.org/243823002/40001

[commit-bot: I haz the power, 2014-04-22 00:03:33]

Change committed as 172094