54582 2011-02-16 13:53:58 -0800 REGRESSION (r73756 ): Some page content not displaying correctly at pay.37wan.com 2011-02-16 16:34:26 -0800 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) All All RESOLVED WONTFIX P2 Normal --- 47397 1 adele webkit-unassigned abarth aestes ap dimich ian jennb oldest_to_newest 352311 0 82686 adele 2011-02-16 13:53:58 -0800 Created attachment 82686 test Steps to reproduce: 1. Navigate to http://www.37wan.com/. 2. Enter username into top text field 3. Enter password into bottom text field 4. Press login button (left orange button). 5. Press index button (Middle yellow button within orange box). --Result: Most of the text on the page is character garbage. If you don't have a login, please see the attached reduction, which is the following markup: <meta http-equiv="Content-Type" contet="text/html; charset=UTF-8" /> 充值中心| webgame-37wan网页游戏平台 So this site has a typo with "contet". If this works with all shipping browsers, we should probably send feedback to HTML WG, and make a fix. <rdar://problem/9006151> 352315 1 adele 2011-02-16 13:56:45 -0800 This is the change that caused the regression: http://trac.webkit.org/changeset/73756 TextResourceDecoder::checkForHeadCharset can look way past the limit. https://bugs.webkit.org/show_bug.cgi?id=47397 352321 2 aestes 2011-02-16 13:59:47 -0800 Note that this test case isn't quite right since bugzilla is serving it with a correct Content-Type header (text/html; charset=UTF-8). Saving the testcase and opening it locally should do the trick. 352372 3 jennb 2011-02-16 14:43:46 -0800 (In reply to comment #1) > This is the change that caused the regression: > > http://trac.webkit.org/changeset/73756 > TextResourceDecoder::checkForHeadCharset can look way past the limit. > https://bugs.webkit.org/show_bug.cgi?id=47397 Prior to this change, browsers were extremely lenient with charset specification syntax. Something like: <meta http-equiv="Content-Type" foobar="notacharset=UTF-8" /> 充值中心| webgame-37wan网页游戏平台 would still work. As the goal of the change was to make charset detection more precise, I recommend not going backwards even if the above (and the test case for this bug) work with all shipping browsers. 352390 4 ap 2011-02-16 14:59:27 -0800 It's extremely easy to make a typo like the one here - and if it used to work in all browsers, breaking that would be unfortunate. Generally speaking, making parsing more strict is rarely helpful. 352415 5 jennb 2011-02-16 15:38:04 -0800 A small deviation from the spec would be if "http-equiv='Content-Type' is seen in a meta tag, extract "charset=xxx" from other attributes regardless of attribute name. If this sounds acceptable, I'll make the change. 352416 6 abarth 2011-02-16 15:39:22 -0800 (In reply to comment #5) > A small deviation from the spec would be if "http-equiv='Content-Type' is seen in a meta tag, extract "charset=xxx" from other attributes regardless of attribute name. > > If this sounds acceptable, I'll make the change. You should probably grab Hixie on #whatwg and touch base with him before implementing that change. 352428 7 ian 2011-02-16 16:04:24 -0800 From what I can tell, this would be a wrong change. In particular, if it was correct, I'd expect all the browsers to get a "fail" (1252) on this test case, but every browser I tested gets a "pass" (1254): http://www.hixie.ch/tests/adhoc/html/parsing/encoding/142.html (To control for declaration order, I also have this test: http://www.hixie.ch/tests/adhoc/html/parsing/encoding/143.html ...which seems to indicate the issue is not that browsers are just using the last one.) 352448 8 ian 2011-02-16 16:31:53 -0800 Looks like IE8, FF4, Opera 11, and the next versions of WebKit and Chrome will all break this page in the same way. I would vote to leave it broken. The alternative is making the parsing of charset decls way more complicated and breaking away from IE8 compat on this issue, which seems suboptimal. 82686 2011-02-16 13:53:58 -0800 2011-02-16 13:53:58 -0800 test 37wan.html text/html 115 adele PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZXQ9InRleHQvaHRtbDsgY2hhcnNl dD1VVEYtOCIgLz4K5YWF5YC85Lit5b+DfCB3ZWJnYW1lLTM3d2Fu572R6aG15ri45oiP5bmz5Y+w Cg==