The page in Browser has meta charset info and if you want to change the charset menu in browser, the charset menu does not inherite into composer. 1. Go to http://babel/tests/browser/charoverride/nonframe/jawrongmeta.html (This page has wrong meta charset info -koi8-r) 2. Change Character coding to Japanese (Shift_JIS) 3. Select menu File|Edit page to open composer In the composer, Cyrillic(koi8-r) menu item is marked. Japanese (Shift_JIS) should be marked. Tested 2001-05-08-04 build.
Changed QA contact to email@example.com and added intl keyword.
QA Contact: andreasb → ylong
OK, it looks like we'll have to force the browser window charset in composer. Adding Kat to the mailing list. I recall that we didn't want to give user override a priority over the meta tag or HTTP header - see bug 21313, bug 18022. The current priority hierarchy can be seen here (in reversed order): http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsIParser.h#85 The concern we had with the RFC compliance might not apply to the composer, since we are really just editing a snapshot of the original source. accepting, targeting 1.0, this is related to 56195.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
We allow the user override of HTTP or document charset specification anyway. And so, the issue raised here probably only applies to the encoding setting when a composer document is opened from a loaded page. The spec we agreed on says that in this case the "Current Document Encoding" should be honored. The current document encoding is whatever the menu checkmark says what it is at a given moment. If the user has overridden the HTTP or document charset, then the current document encoding would be that choice made by the user. That means what is reported here is a bug by this criterion.
remove moz1.0 it does not make sense for us.
Target Milestone: mozilla1.0 → ---
Looks like edge cases. move it to future.
Target Milestone: --- → Future
resummarizing and cc'ing cmanske for "editor.js" changes, alecf and ben for the "utilityOverlay.js" modification...
Summary: Overwritten charset in Browser does not inherite into Composer. → User-overidden browser charset does not inherite into the composer window
Summary: User-overidden browser charset does not inherite into the composer window → User-overridden browser charset does not propagate into the composer window
cmanske, ftang: could you help reviewing this?
The editor.js changes seem good to me. r=cmanske
blake/ben: do you find anything objectionable with the proposed changes to utilityOverlay.js? cmanske: thanks for looking over the patch!
Whiteboard: have fix, need sr
thanks a lot Chris! Updating whiteboard summary.
Whiteboard: have fix, need sr → Ready to land - waiting for the tree to open
another one bites the dust - thanks everyone!
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: Ready to land - waiting for the tree to open → fixed on the trunk
Verified it on 08-22 trunk build: Not the page is displayed correctly after you manually change to right charset. So the original problem has been fixed. However, in Composer, the charset still can not be marked as the correct one( in this case, x-jis) from View | Character Coding menu, I'll file a seperate bug for that.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.