New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 363974 link

Starred by 1 user

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Apr 2014
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Sign in to add a comment

Rendering of <pre> block doesn't write elements line by line

Reported by, Apr 16 2014

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.27 Safari/537.36 OPR/22.0.1473.0 (Edition Developer)

Steps to reproduce the problem:
1. Go to  
3. Enter any web address

What is the expected behavior?
All elements in <pre> tag should be written line by line - behaviour of other browsers

What went wrong?
The block of text from <pre> tag is written to screen when the script is finished. 

Did this work before? No 

Chrome version: 35.0.1913.0  Channel: beta
OS Version: OS X 10.9.2
Flash Version: Shockwave Flash 13.0 r0

Happens on Mac and Windows.

Comment 1 by, Apr 17 2014

Labels: -Cr-UI -Pri-2 -Type-Bug -OS-Mac Cr-Blink-Rendering Pri-1 Type-Bug-Regression OS-All M-33
Status: Assigned
Able to reproduce this on Windows7 on 35.0.1916.27.
Same behavior is seen across all the platforms(Linux,Mac) on latest canary(36.0.1944.0) as well.
This has regressed in M33.

Suspecting r161490??
bjonesbe@:Please reassign if this is not related.


Comment 2 by, Apr 17 2014

r161490 just has renames, so there is no possible way it could have caused this issue.

I haven't dug into it at all (other than reading the change descriptions in the provided revision ranges), but r161488 is much more likely, as it actually changes functionality related to text layout.
It's not clear to me how they're sending down the data to the page at all?

HTTP/1.1 200 OK
Date: Thu, 17 Apr 2014 15:29:54 GMT
Server: Apache/2.4.3 (Unix) OpenSSL/1.0.1g
Expires: Thu, 17 Apr 2014 15:29:54 GMT
Pragma: no-cache
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

I guess via transfer-encoding: chunked

Looks like it works via GET as well:
The original report says "Did this work before? No."  But the second comment says this regressed in M33?  Have we tested in M32 that this worked?
I think this page never works, and I broke incremental loading of text nodes.  I could add a timeout to that batching, but unless we have another case of this it may not be worth it.
Labels: -Cr-Blink-Rendering Cr-Blink-HTML
Actually, it's possible this is a real bug in my code.  I think my code tried to always flush pending text before returning out of the parser.  Presumably pumpTokenizer() should make sure the text is flushed before returning if it doesn't already.
Project Member

Comment 7 by, Apr 22 2014

The following revision refers to this bug:

r172094 | | 2014-04-22T00:03:29.252382Z

Changed paths:

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.

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:
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 

Review URL:
Status: Fixed
I don't think this needs merging.

Sign in to add a comment