*****Observed with win32, linux and Mac OS X 0.9.4 build**** On a page with frames, changing charset doesn't change to the corresponding fonts. Steps to reproduce: 1. Go to http://babel, which is a framed page in ISO-8859-1 encoding. 2. Select menu View | Character Coding | Japanese (Shift-JIS) The charset is changed, but the fonts are not changed to the corresponding fonts.
cc: Kat and shanjian
This is one of the 2 bugs I planned to file. Since ji filed it, let me change the summary line to reflect the general issue involved. http://www.mozilla.org/projects/intl/uidocs/browsercharmenu.html If you look at the browser encoding spec in the above page, i.e. Charset/Encoding Override section, you see that the manual override is supposed to override HTTP, document-charset, auto-detection, etc. This was implemented in documents with no frames, but when frames are present, it is not working for technical reasons. It requires some work and shanjian has promised to work on it in the near future. Essentially, the override logic is that "Any user initiated character coding menu can override: 1) HTTP Charset from server, 2) Meta-charset info in the document, 3) the result of auto-detection, or 4) prior user selection/fallback of the encoding." A user-initiated menu change would be either encoding menu change or auto-detection selection change (or re-selecting the same auto-detection menu item). This same logic of override should apply to both non-frame or frame documents. We should offer the same, intuitively easy-to-understand encoding menu behavior for both types of cases. In this particular example, the 2 frames have their own encoding and they are not overridden by a manual menu change. ylong, we have an internal test cases -- cases 4 and 5, which should correspond to the spec as described above.
Summary: changing charset doesn't change to the corresponding fonts on a page with frames → Let main page manual encoding override persist into frame pages with document charset/hhtp-charset specified
I filed a companion Bug 103960 to cover the auto-detection override case. A manual encoding override is working on pages with no frames with the http or document charset specified. But auto-detection override is not working at all right now if the page(s) has http or document charset specified. So we need to deal with this latter problem separately. This bug probably should go to shanjian.
Kat, when I change charset on http://babel, the charset mark on the charset menu is placed to the right place. Does this mean the charset is actually not changed (since the fonts are not changed) although from the charset menu you don't see any problem?
> Does this mean the charset is actually not changed (since > the fonts are not changed) although from the charset menu you > don't see any problem? It is changed in the main page -- but this change no effect on frame pages with their charset specified. That is why the font does not change. I think it will be a lot easier to see this effect with my frame override test cases available NS-internally.
shanjian- please look at this one. Not sure this is high priority or not.
Assignee: yokoyama → shanjian
Modified a summary line slightly for readability.
Summary: Let main page manual encoding override persist into frame pages with document charset/hhtp-charset specified → Let main page manual encoding override persist into frame pages with document or http charset specified
Set tm to 1.01, but hoping to get it fixed sooner than that.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
*** This bug has been marked as a duplicate of 112793 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
The original problem can not be reproduced on recently trunk build. Mark it as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.