Summary: | Investigate not using the frameset charset as a default for frames | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||
Component: | DOM | Assignee: | Alexey Proskuryakov <ap> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | ||||||
Priority: | P2 | ||||||
Version: | 420+ | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
URL: | http://images.google.com/imgres?imgurl=http://www.galicianos.com/media/luar%2520na%2520lubre-cabo%2520do%2520mundo.jpg&imgrefurl=http://www.galicianos.com/folk.html&h=260&w=260&sz=23&tbnid=e-QF8j69jqcJ:&tbnh=107&tbnw=107&hl=en&start=9&prev=/images%3Fq%3DLuar%2BNa%2BLubre%2BCabo%2BDo%2BMundo%2B%26hl%3Den%26lr%3D%26c2coff%3D1%26sa%3DG | ||||||
Attachments: |
|
Description
Alexey Proskuryakov
2005-12-17 03:21:58 PST
Using the parent frame encoding as a default is intentional, see rdar://3100151 (subframes without explicit charset settings should inherit from parent, not use default). I cannot see the bug contents, thus have no idea about the reason, and I'm going to propose a patch that reverts this change :) Created attachment 5150 [details]
proposed patch
Comment on attachment 5150 [details] proposed patch Do not use the parent frame encoding as a default for sub-frames (revert rdar://3100151). Fixes displaying of Google Images search results. Here's the original bug report: Text from reporter: "When subframes don't have the charset, it should inherit the setting from the parent page. The HTML spec doesn't say anything about this implicit inheritance, but other browsers including IE, Mozilla, and OmniWeb do it. "* STEPS TO REPRODUCE: "0) Change your text encoding setting to 'Western (ISO Latin 1)' in Pref panel's Display pane. "1) Go to http://www.2ch.net/2ch.html "RESULT: the left side frame is garbled." Then later: "Correction. "It's only Mozilla that behaves this way. IE and OmniWeb don't propagate the setting." So we need to test this Japanese site with the patched behavior. If Mozilla does continue to work with this site, then we have to figure out why. Currently, this site provides a correct charset in HTTP headers, so it should work with any browser (tested WebKit with and without this patch, Firefox 1.5 and Opera 8.5). Assuming the analysis in rdar://3100151 was correct, I suppose that Mozilla/Firefox have been brought in line with IE since then, so reverting its fix should be a right and safe thing to do. Later a comment from the International "bug review" group at Apple: "This is a common situation in, eg, Japanese web pages. It would seem that propagating to at least unlabeled frames would be the right thing to do." OK, here's our theory. At the time this bug was written, Mozilla did propagate the encoding to subframes. Since then, it was fixed to behave the same way other browsers do. And the http://www.2ch.net/2ch.html website was fixed too. So now WebKit is left as the odd one out, with a rule that Mozilla once had in the past but no longer has. So we think we should take this patch. Comment on attachment 5150 [details]
proposed patch
Test should probably use "about:blank" instead of "about:", but "about:" will
work.
r=me
|