Bug 6118 - Investigate not using the frameset charset as a default for frames
Summary: Investigate not using the frameset charset as a default for frames
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Alexey Proskuryakov
URL: http://images.google.com/imgres?imgur...
Depends on:
Reported: 2005-12-17 03:21 PST by Alexey Proskuryakov
Modified: 2005-12-23 00:30 PST (History)
0 users

See Also:

proposed patch (5.12 KB, patch)
2005-12-19 05:42 PST, Alexey Proskuryakov
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2005-12-17 03:21:58 PST
This site reports UTF-8 for the main document, but uses Latin1 in all the frames without specifying it. 
Safari defaults to UTF-8, Firefox doesn't.

For me, this makes little difference (I have windows-1251 set as a default in both browsers), but for 
people with Latin-1 default in Firefox, the page looks OK.
Comment 1 Alexey Proskuryakov 2005-12-19 05:29:36 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 :)
Comment 2 Alexey Proskuryakov 2005-12-19 05:42:32 PST
Created attachment 5150 [details]
proposed patch
Comment 3 Alexey Proskuryakov 2005-12-19 05:46:11 PST
Comment on attachment 5150 [details]
proposed patch

Do not use the parent frame encoding as a default for sub-frames (revert
Fixes displaying of Google Images search results.
Comment 4 Darin Adler 2005-12-19 08:53:43 PST
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.

"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:

"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.
Comment 5 Alexey Proskuryakov 2005-12-19 09:14:03 PST
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.
Comment 6 Darin Adler 2005-12-19 09:42:09 PST
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."
Comment 7 Darin Adler 2005-12-19 12:50:09 PST
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 8 Darin Adler 2005-12-19 12:50:54 PST
Comment on attachment 5150 [details]
proposed patch

Test should probably use "about:blank" instead of "about:", but "about:" will