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.
Looks like separate text nodes are being created for each data chunk (whatever defines the chunk)... Can the same happen with normal HTML?
(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).
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
(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.
Created attachment 8638 [details] Use innerText for plain text files
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.
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.