fast/encoding/japanese-encoding-mix.html fails on Tiger after enabling HTML5 Lexer It looks like Tiger's decoders are not properly passing the --> off to the HTML Lexer so it never sees an end to the comment. --- /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/layout-test-results/fast/encoding/japanese-encoding-mix-expected.txt 2010-06-16 09:19:19.000000000 -0700 +++ /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/layout-test-results/fast/encoding/japanese-encoding-mix-actual.txt 2010-06-16 09:19:19.000000000 -0700 @@ -1,5 +1,12 @@ -Some text here is encoded as EUC-JP, and some (in comment) as Shift_JIS. Since there is an explicit encoding declaration, auto-detection shouldn't change the encoding. - -ニッãƒãƒ³ãƒ†ãƒ¬ãƒ“ - -Should be EUC-JP: EUC-JP +layer at (0,0) size 800x600 + RenderView at (0,0) size 800x600 +layer at (0,0) size 800x600 + RenderBlock {HTML} at (0,0) size 800x600 + RenderBody {BODY} at (8,8) size 784x576 + RenderBlock {P} at (0,0) size 784x36 + RenderText {#text} at (0,0) size 774x36 + text run at (0,0) width 774: "Some text here is encoded as EUC-JP, and some (in comment) as Shift_JIS. Since there is an explicit encoding declaration," + text run at (0,18) width 288: "auto-detection shouldn't change the encoding." + RenderBlock {P} at (0,52) size 784x21 + RenderText {#text} at (0,3) size 112x18 + text run at (0,3) width 112: "\x{30CB}\x{30C3}\x{30DD}\x{30F3}\x{30C6}\x{30EC}\x{30D3}"
Bug 40661 is the same failure except for Qt (which also has different decoders).
Skipping the test for now. This bug should remain open to track the failure (at least for as long as Tiger is still a real platform... which can't be that much longer now).
Committed r61266: <http://trac.webkit.org/changeset/61266>
The fix would be to just add a space before --> to insulate the test from EUC-JP decoder differences.
That's fine too. Do we care about testing the encoder differences?
I don't think we should try to test edge cases of complex decoders like this, unless we suspect that particular bugs may have security implications.
Created attachment 58952 [details] Patch
Comment on attachment 58952 [details] Patch + Qt and Tiger seem to have encoding problems that swallow the -- I think it's only one character after an invalid sequence that gets swallowed. r=me
Comment on attachment 58952 [details] Patch Wow. I don't think this was ever landed. :(
Comment on attachment 58952 [details] Patch Rejecting patch 58952 from commit-queue. Failed to run "[u'/Users/eseidel/Projects/CommitQueue/WebKitTools/Scripts/svn-apply', u'--reviewer', u'Alexey Proskuryakov', u'--force']" exit_code: 1 Parsed 4 diffs from patch file(s). patching file LayoutTests/ChangeLog Hunk #1 succeeded at 1 with fuzz 3. patching file LayoutTests/fast/encoding/japanese-encoding-mix.html patching file LayoutTests/platform/mac-tiger/Skipped Hunk #1 FAILED at 194. 1 out of 1 hunk FAILED -- saving rejects to file LayoutTests/platform/mac-tiger/Skipped.rej patching file LayoutTests/platform/qt/Skipped Hunk #1 FAILED at 5417. 1 out of 1 hunk FAILED -- saving rejects to file LayoutTests/platform/qt/Skipped.rej Full output: http://queues.webkit.org/results/3734061
Created attachment 64136 [details] Patch for landing
Comment on attachment 64136 [details] Patch for landing Clearing flags on attachment: 64136 Committed r65211: <http://trac.webkit.org/changeset/65211>
All reviewed patches have been landed. Closing bug.