I'm filing this bug to make a formal request that we put in a
charset override mechanism for the Browser. We have had an internal
document for the earlier 5.0 specification:
which could be useful in looking at issues raised earlier.
It is not necessary that we follow the recommendations there
but we should at least be able to address the issues there
with our new spec. If enough people are interested in
reading the override pasrt of this document, I'll be happy
to externalize that part as a separate file.
There is also a somewhat related issue for Editor, which needs
to address some Editor-sepcific issues.The Editor specs for
the old 5.0 project is here:
The Mail pasr of the request was filed as; Bug 5938.
Our hope is that we should come up with a consistent
UI for the override taking into account various needs
I'll add more comments later.
Mark this as a M10 feature.
Move to M11
this have dependency on cata's encoding menu work. Since he won't make it untill
next Monday, I don't think I can work on this in M11. Move to M12
reassign to cata.
Should considering use "Shift-" menu select for "Charset Override" ? Momoi- what
is the currenty ui spec say?
Cata, please put a pointer to the spec in this bug report.
Frank, I think the Shift menu selection is too obscure. Users want the menu to
have an effect when they select something, even without the Shift key.
My current proposal is that:
"Changing a Character encoding menu on a page with a meta tag which
has been loaded already triggers Charset override. The override
is one time only and will not persist. This way it will not
require any additional UI."
This proposal is contained in this document (See the section on
I'll be updating this document as it relates to Charset menu UI
according to the more recent UI proposal in the Editor UI document
and also other-lang related preferences.
I've looked at IE5 for charset override behavior and it simply
override any meta tag if you choose a menu item other than the
one that is the current document charset. This does not persist
and you can override it any number of times with different
I also agree with Erik that using special key is not needed.
I think we want this to be a easily discoverable process and
changing a menu is what the users are used to already.
Out of time for M13, moving to M14.
change platform to ALL
change OS to ALL
Added beta1 for Encoding menu functional.
Changed QA contact to email@example.com.
ETA moved to 15.
Cata, I cleared the ETA. Please update with new ETA.
I'm not done yet. I think tomorrow it'll be ready.
This will become a pdt- on friday if you don't make tomorrow. Good luck! ;-)
cata has a fix that seems to be working in his local tree. But he needs
to review his code and discuss with ftang and do some thorough testing
before checking in. It won't be checked in today. We probably will check
in early next week or post-Beta1 depending upon the review and testing.
Either get this reviewed an in RSN, or get it off the radar. Your last comment
suggests that you are willing to later it (post beta). One way or the other,
lets move this one along.
Please update the status whiteboard with a landing date if it is going in now.
No, we still want this for beta. I am almost done with the latest revision of my
patch, we have a set of tests, and QA is ready to hammer on it. Check-in date
is tomorrow or Friday the latest.
Ok. the charset override has been activated. Remaining work is post-beta, bug
If the fix was backed out, shouldn't this bug be reopened?
Fix was backed out. It caused regression #30299
Removed this from beta1 candidacy.
cata- please clean up the REOPEN state and mark it ASSIGN. And please state
clearly what kind of regression you introduce last time so QA can verify when
you fix this later.
*** Bug 30169 has been marked as a duplicate of this bug. ***
Putting on [nsbeta2+] radar.
Implemented. For now, it is activated only when you add the following line in
your prefs file: pref("intl.charset.override", "yes");
QA, please activate and test it. Fill the eventual bugs against me...
Changed QA contact to firstname.lastname@example.org.
I tested this in 2000-05-30 Win32 build, the override in the following specs does not work.
An override will not persist if a new document is loaded or Super-reload of the same document is chosen(?) -- see below for Issues.
Steps of reproduce
1. Put user_pref("intl.charset.override", "yes"); in prefs.js file
2. Start Netscape
3. Go to http://home.netscape.com/ja/
4. Select Character coding ->Multibyte->Japanese(EUC-JP)
The page is tried to loaded as EUC-JP. The Japanese characters are displayed
garbage. (This is correct.)
5. Go to http://home.netecape.com/ko/
The page is displayed the different Kanji characters. This page is not in
If new document is loaded, the override is not persist. So, this page is loaded as Korean (EUC-KR) since this page has meta charset info.
M16 has been out for a while now, these bugs target milestones need to be
I'm marking this bug fixed againb, as the override is not supposed to be
persistent. It is only supposed to survive a simple "reload". But that is marked
in different bugs: 43530 and 43529.
I verified this in 2000-06-30-08 Win32, Mac, and Linux build.