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




18 years ago
18 years ago


(Reporter: teruko, Assigned: jbetak)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: fixed on the trunk, URL)


(2 attachments)



18 years ago
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.

Comment 1

18 years ago
Changed QA contact to and added intl keyword.
Keywords: intl
QA Contact: andreasb → ylong

Comment 2

18 years ago
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.

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

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.

Target Milestone: --- → mozilla1.0

Comment 4

18 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

18 years ago
remove moz1.0
 it does not make sense for us. 
Target Milestone: mozilla1.0 → ---

Comment 6

18 years ago
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
Created attachment 44848 [details] [diff] [review]
Patch #2 (cvs diff -u -w  -b)
cmanske, ftang:  could you help reviewing this?

Comment 12

18 years ago
The editor.js changes seem good to me. r=cmanske
blake/ben: do you find anything objectionable with the proposed changes to 

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!
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: Ready to land - waiting for the tree to open → fixed on the trunk

Comment 17

18 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.
You need to log in before you can comment on or make changes to this bug.