Closed Bug 7886 Opened 26 years ago Closed 25 years ago

Charset Override mechanism needed for browser

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: momoi, Assigned: cata)

References

Details

(Whiteboard: [nsbeta2+])

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.
Blocks: 5938
Status: NEW → ASSIGNED
Target Milestone: M10
Mark this as a M10 feature.
Target Milestone: M10 → M11
Move to M11
Target Milestone: M11 → M12
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
Assignee: ftang → cata
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Target Milestone: M12 → M13
Blocks: 20761
Target Milestone: M13 → M14
Out of time for M13, moving to M14.
change platform to ALL
Hardware: PC → All
change OS to ALL
OS: Windows NT → All
Added beta1 for Encoding menu functional.
Keywords: beta1
Whiteboard: [pdt+]
Changed QA contact to amasri@netscape.com.
QA Contact: teruko → amasri
Whiteboard: [pdt+] → [pdt+] ETA: 11/Feb
ETA moved to 15.
Whiteboard: [pdt+] ETA: 11/Feb → [pdt+] ETA: 15/Feb
Cata, I cleared the ETA. Please update with new ETA.
Whiteboard: [pdt+] ETA: 15/Feb → [pdt+]
Whiteboard: [pdt+] → [pdt+] ETA: 23/Feb
I'm not done yet. I think tomorrow it'll be ready.
Whiteboard: [pdt+] ETA: 23/Feb → [pdt+] ETA: 24/Feb
This will become a pdt- on friday if you don't make tomorrow. Good luck! ;-)
Whiteboard: [pdt+] ETA: 24/Feb → [pdt+] ETA: 24/Feb I have a fix, but I am not very confident about possible side effects.
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.
Whiteboard: [pdt+] ETA: 24/Feb I have a fix, but I am not very confident about possible side effects. → [pdt+] ETA: 24/Feb I have a fix, but need to review potential side effects
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.
Whiteboard: [pdt+] ETA: 24/Feb I have a fix, but need to review potential side effects → [pdt+] ETA: 2/Mar I have a fix, but need to review potential side effects
Ok. the charset override has been activated. Remaining work is post-beta, bug #30169
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Whiteboard: [pdt+] ETA: 2/Mar I have a fix, but need to review potential side effects → [pdt+] done.
If the fix was backed out, shouldn't this bug be reopened?
Fix was backed out. It caused regression #30299
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
No longer blocks: 5938
Removed this from beta1 candidacy.
Keywords: beta1
Whiteboard: [pdt+] done.
Target Milestone: M14 → M16
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. ***
Status: REOPENED → ASSIGNED
Keywords: beta2
Blocks: 28284
Blocks: 28740
Keywords: nsbeta2
Putting on [nsbeta2+] radar.
Keywords: beta2
Whiteboard: [nsbeta2+]
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...
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
Changed QA contact to teruko@netscape.com.
QA Contact: amasri → teruko
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
I verified this in 2000-06-30-08 Win32, Mac, and Linux build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.