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)
Core
Internationalization
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: teruko, Assigned: jbetak)
References
()
Details
(Keywords: intl, Whiteboard: fixed on the trunk)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
Changed QA contact to ylong@netscape.com and added intl keyword.
Keywords: intl
QA Contact: andreasb → ylong
Comment 2•24 years ago
|
||
Assignee | ||
Comment 3•24 years ago
|
||
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
Comment 4•23 years ago
|
||
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.
Comment 5•23 years ago
|
||
remove moz1.0
it does not make sense for us.
Target Milestone: mozilla1.0 → ---
Assignee | ||
Comment 7•23 years ago
|
||
Assignee | ||
Comment 8•23 years ago
|
||
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
Assignee | ||
Comment 9•23 years ago
|
||
resummarizing
Summary: User-overidden browser charset does not inherite into the composer window → User-overridden browser charset does not propagate into the composer window
Assignee | ||
Comment 10•23 years ago
|
||
Assignee | ||
Comment 11•23 years ago
|
||
cmanske, ftang: could you help reviewing this?
Comment 12•23 years ago
|
||
The editor.js changes seem good to me. r=cmanske
Assignee | ||
Comment 13•23 years ago
|
||
blake/ben: do you find anything objectionable with the proposed changes to
utilityOverlay.js?
cmanske: thanks for looking over the patch!
Assignee | ||
Updated•23 years ago
|
Whiteboard: have fix, need sr
Comment 14•23 years ago
|
||
sr=blizzard
Assignee | ||
Comment 15•23 years ago
|
||
thanks a lot Chris! Updating whiteboard summary.
Whiteboard: have fix, need sr → Ready to land - waiting for the tree to open
Assignee | ||
Comment 16•23 years ago
|
||
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
Comment 17•23 years ago
|
||
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.
Description
•