RESOLVED FIXED 8996
slow-utf8-text layout test case failing (no longer deterministic?) 
https://bugs.webkit.org/show_bug.cgi?id=8996
Summary slow-utf8-text layout test case failing (no longer deterministic?)
Darin Adler
Reported 2006-05-19 08:53:01 PDT
The slow-utf8-text test case does not seem to yield deterministic results any more, so we're getting test failures. These may have been introduced with recent changes to standalone text viewing.
Attachments
Use innerText for plain text files (68.76 KB, patch)
2006-06-01 04:58 PDT, Anders Carlsson 		timo: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2006-05-19 13:10:40 PDT
Looks like separate text nodes are being created for each data chunk (whatever defines the chunk)... Can the same happen with normal HTML?
Darin Adler
Comment 2 2006-05-19 13:48:29 PDT
(In reply to comment #1) > Looks like separate text nodes are being created for each data chunk (whatever > defines the chunk)... Can the same happen with normal HTML? No, that won't happen with the HTML parser. I believe Anders did this intentionally for performance reasons, but we spoke about it afterward and I argued that we should investigate the performance problem, fix it, and change it. The code in question is straightforward (in TextTokenizer).
Anders Carlsson
Comment 3 2006-05-27 23:59:15 PDT
Another solution would be to use textContent for HTML documents (and not dump the render tree) when we know that the MIME type is txt
Darin Adler
Comment 4 2006-05-30 10:58:09 PDT
(In reply to comment #3) > Another solution would be to use textContent for HTML documents (and not dump > the render tree) when we know that the MIME type is txt That sounds like a good idea too.
Anders Carlsson
Comment 5 2006-06-01 04:58:19 PDT
Created attachment 8638 [details] Use innerText for plain text files
Darin Adler
Comment 6 2006-06-01 10:30:01 PDT
Comment on attachment 8638 [details] Use innerText for plain text files I think the use of |= is not great. I'd just use an if statement, or a separate boolean. But that's an unimportant nitpick; the change looks good. r=me As far as the WebFrameView change is concerned, what's the effect of that? Does it make some pages display that would download otherwise? I think the change is good, but should probably be landed separately, since it's not part of the fix for this bug.
Anders Carlsson
Comment 7 2006-06-01 10:33:39 PDT
It is part of the bug fix, because [frame DOMDocument] will return nil if you pass it a document with a MIME type of "text/plain" otherwise.
Note You need to log in before you can comment on or make changes to this bug.