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: http://warp/GApps/intl/gromit/gromitencode.html#feedback 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: http://warp/GApps/intl/gromit/gromitcomposer.html 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 involved. 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 Charset override.) http://rocknroll/users/momoi/publish/seamonkey/50intlui.html 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 selections.
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 firstname.lastname@example.org.
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. Thanks, Jim
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 #30169
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 email@example.com.
I tested this in 2000-05-30 Win32 build, the override in the following specs does not work. http://rocknroll/users/momoi/publish/seamonkey/5_0intlbrowsermenudft2.html Charset Override: 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 Korean characters. 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 updated.
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.