Closed Bug 79735 Opened 24 years ago Closed 23 years ago

User-overridden browser charset does not propagate into the composer window

Categories

(Core :: Internationalization, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: teruko, Assigned: jbetak)

References

()

Details

(Keywords: intl, Whiteboard: fixed on the trunk)

Attachments

(2 files)

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 ylong@netscape.com and added intl keyword.
Keywords: intl
QA Contact: andreasb → ylong
I think it is very similar with bug 77229 which was marked as dup of 45408. But note both this one and bug 77229 has wrong meta-tag and bug 45408 doesn't has meta-tag in original page.
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
resummarizing
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
sr=blizzard
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
Closed: 23 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.

Attachment

General

Created:
Updated:
Size: