In the Character set menu, the mark in the menu which character set is selected is missing. Steps of reproduce 1. Launch Apprunner 2. Go to http://home.netscape.com/ja/ 3. Select menu View|Character set->Japanese (Shift_JIS) 4. Select menu View|Character set At that time, the Japanese(Shift_JIS) menu should be marked. Tested 8-12-10 Win32 and MAC, 8-10 Linux build.

reassigning to saari for triage

Dup of another bug about checked items

Dup of another bug about checked items

Mac and XPMenus can display check marks now if you set checked="true" on a menuitem. However, hyatt and myself have more plans for this, so I'm leaving the bug open

type="checkbox" works for MacOS now. Pushing the XPMenu part of this to M11

*** Bug 14664 has been marked as a duplicate of this bug. ***

*** Bug 15131 has been marked as a duplicate of this bug. ***

shaver, this is yours. Thanks!

<menuitem type="checkbox"/> works now in XPMenus, so this is up to the owners of those menus.

reassigning to cata

Moved to M12, not going to make it for M11...

Checkmark code reviewed by erik and ready for checkin. This adds an API on the charset menu code. This API will set the the checkmark for an item. However, this will not be visible until we hook up the event code (bug #24030) that will call this API.

So, this is fixed. Again, mark is not visible just yet, because we don't set it. But that's bug #24030, the code for this bug is all in and tested.

I do not think I can verify this in M13 since the mark is not visible. I would like to reopen this to keep track and change M14.

Actually, it is visible. If you use one of the charsets from the "Character Set" menu (not "More") a checkmark will appear. Not being connected with the events, it is does not have a consistent behaviour. But you can see it...

Putting on PDT+ radar for beta1.

Cata, I see the mark under your character set menu. However, the mark is not visible in the other character set menu and function is not working. This should be fixed in beta1.

Fixed.

I verified this in 2000022108 Win32 and Linux build. However, this does not work in 200022108 and 2000021808 Mac build.

This does not work in 2000021608 Mac build.

I assume the current status (not working on Mac) is dependent upon bug 27947 "oncreate"/"ondestroy" are never fired for mac menus

*** Bug 28739 has been marked as a duplicate of this bug. ***

Putting on pdt- radar, will release note for Mac.

IQA, Please try this in tomorrow's (2/25) build. It should be fixed by the fix for bug 27947.

The bug #11774 depends on was fixed. This should work now. Only needing verification.

I tested this in 2000030108 Win32, MAC, and 2000030113 Linux build. Win32 and Linux After Mozilla.exe is launched, only Auto-Detect off menu is marked under the View|Character Coding Menu. Then, I go to www.yahoo.co.jp and select menu View|Character Coding ->Multibyte->Japanese (EUC-JP), Japanese (EUC-JP) will go to under Character Coding menu, but it is not marked. Even I select Auto-Detect (Japanese) menu, the menu is not marked. This might be releted the bug 29661 which is dup to bug 25073. MAC After Mozilla.exe is launched, Auto-Detect off menu and Western (ISO-8859-1) are marked under the View|Character Coding Menu. Then, I go to www.yahoo.co.jp and select menu View|Character Coding ->Multibyte->Japanese (EUC-JP), Japanese (EUC-JP) will go to under Character Coding menu, but it is marked. At this time, both Western (ISO-8859-1) and Japanese (EUC-JP) menu are marked. Only Japanese (EUC-JP) menu should be marked. I need to reopen this. Auto-Detect menu is marked correctly.

Bug 25073 was fixed on 3/7. Has this bug been retested?

Unfortunately, there's a new regression for radio menus on Mac. We are depending on 31104 now.

cata, please clean up REOPEN and mark it ASSIGN if you are working on this bug. (or waiting for the depend bug)

This looks horrible and the user has no idea what the setting is. Here is an update from teruko: I tested this in 3-17-12 nb1b Mac build. Everytime I select one of View|Character coding, it added to the list, but everything is marked. For example, 1. Launch Navigator 2. Look at the menu under View|Character coding Western (ISO-8859-1) menu is marked 3. Go to http://babel/automation/websites/altavista 4. Select menu View|Character coding->Multibyte->Korean(Euc-KR) 5. Check menu View|Character coding There are 2 menu Western (ISO-8859-1) and Korean (EUC-KR) under Character coding menu, but both menus are marked. In mac, marking check in the Character coding menu is not consistant.

The bug we depend on (#31104) is marked M18. I'm moving this to M16, in the hope that I'll have the time to take a look at that myself. Or maybe Pink will change his mind. But don't hold your breath...

This is a bugfix, not feature - moving to M17.

OK, I need to include this in the Rel notes. It seems that the major problem is in Mac and Win & Linux have minor problems. Does this accurately describe the remaining bug?

On Windows, I'm seeing the checkmark is not being updated under Auto-Detection setting. For example, if the first site is in Shift_JIS which is reflected in the checkmark, but when we go visit another site which is EUC-JP but not marked in the document, Auto-detection can display is but the checkmark is not refreshed. This is not as bad as Mac described above.

On Mac, the marking check in the Character coding menu is not consistant. For example, 1. Launch Navigator 2. Look at the menu under View|Character coding Western (ISO-8859-1) menu is marked 3. Go to http://babel/automation/websites/altavista 4. Select menu View|Character coding->Multibyte->Korean(Euc-KR) 5. Check menu View|Character coding There are 2 menu Western (ISO-8859-1) and Korean (EUC-KR) under Character coding menu, but both menus are marked. 6. Go to http://www.yahoo.co.jp 7. Select menu View|Character Coding->Japanese(Euc-JP) 8. Check again menu View|Character coding There are 2 menu Western (ISO-8859-1), Korean (EUC-KR), and Japanese (Euc-JP) under Character coding menu. Western and Korean menus are marked, but Japanese (EUC-JP) is not marked. Tested 2000032800 Mac build.

Putting on [nsbeta2+] radar for beta2 fix.

The bug we were depending on was fixed, so...

This still is not working correct in 2000-06-09-08-M17 Mac build.

*** Bug 31708 has been marked as a duplicate of this bug. ***

Updating the bug to reflect the current situation.

Nominating this for beta2.

Putting on [nsbeta2-] radar. Not critical to beta2.

*** Bug 45632 has been marked as a duplicate of this bug. ***

This is not generic Mac check mark issue. This is only Character Coding menu problem.

Reassign to myself for now.

Putting on the [nsbeta2-] radar.

mark as assign

mark it as assign

pinkerton- we need your help here. I put some dump code into the JavaScript which will set the "checked" to "true" for those menu item. I also put some printf in the nsMenu.cpp SetCheckMark method. Somehow they looks different. Do we play some trick on Mac for those menu code ? How can I make sure the nsIDOMDocuemnt the JavaScript setting is the same one that the menu code is pulling ?

need some help from someone understand XUL and Mac menu

i'm confused, what's the problem?

somehow the problem is fixed by someone else. I can no longer reproduce this problem. Mark it as work for me now.

I tested this in 2000-09-06-04 Mac build. This still happens. Steps of reproduce 1. Create new profile and launch Netscape 6 2. Go to http://www.yahoo.co.jp/ 3. Select menu View|Character Coding-> More->East Asian->Japanese(EUC-JP) 4. Select menu View|Character Coding The menu Western (ISO-8859-1) has a check mark. Japanese (EUC-JP) should have a check mark. 5. Go to http://www.zdnet.co.jp/ 6. Select menu View|Character Coding The menu Western (ISO-8859-1) still has a check mark. Japanese (Shift_JIS) should have a check mark. I reopen this bug.

I think this is not a generic Mac menu problem. I try Composer and select Heading 1 from the toolbar dropdown and it does reflect correctly in the menu. Currently, we use the following code to check the check mark

121 function UpdateCurrentCharset() 122 { 123 var wnd = document.commandDispatcher.focusedWindow; 124 if (window == wnd) wnd = window._content; 125 126 var charset = wnd.document.characterSet; 127 dump("Update current charset: " + charset + "\n"); 128 129 var menuitem = document.getElementById('charset.' + charset); 130 131 if (menuitem) { 132 menuitem.setAttribute('checked', 'true'); 133 } 134 } in http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/charsetOve rlay.js#127

I take my previous comment back. I think this is a generic problem on Mac menu I can reproduce this problem on Composer- see 51957. Could be related to 51685

reassign this to pinkerton

i think this is now a dupe of 51685, a recent regression.

51685 down, closing this out

I tested this in 2000-09-11-08 Mac build. This still happens. Steps of reproduce 1. Create new profile and launch Netscape 6 2. Go to http://www.yahoo.co.jp/ 3. Select menu View|Character Coding-> More->East Asian->Japanese(EUC-JP) 4. Select menu View|Character Coding The menu Western (ISO-8859-1) has a check mark. Japanese (EUC-JP) should have a check mark. 5. Go to http://www.zdnet.co.jp/ 6. Select menu View|Character Coding The menu Western (ISO-8859-1) still has a check mark. Japanese (Shift_JIS) should have a check mark. 7. Go to http://home.netscape.com/ja 8. Select menu View|Character Coding The menu Western (ISO-8859-1) still has a check mark. Japanese (Shift_JIS) should have a check mark. I reopen this bug.

oooh chriiiiiiiiiiis ;)

try this again, it seems to work fine, at least far as I can tell

I tested this in 2000-09-13-12 Mac build. This is still reproduciable.

from teruko's steps, it works fine up to step six, where Japanese EUC-JP is still checked, not Japanese Shift_jis Step 4 says western is incorrectly checked, I do not find that to be the case. Step 4 has the correct option selected.

So the act of going to a new site should magically select a new charset. How does it do that? Attribute setting or during the construction of the menu?

nsbeta3-/future. This does not fit the P1/P2 criteria established by PDT, IMO, since there is no crash, data loss, functional loss, standards failure, or major contractual requirement; and the incorrect behavior is low profile. Feel free to escalate to PDT if you think otherwise.

Targeting Mozilla 1.0

Changed QA contact to ylong@netscape.com.

nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)

this is so not dogfood

I think she meant CatFood.

Pls re-eval for M0.9.2.

Um, because ... ? There isn't even a statement of substance in here in since Sept. 2000. Has i18n QA confirmed that this is still a bug?

This still happens in 2001-05-29-08 Mac Trunk build. If the page has meta-charset info, the check mark in Character coding menu does not indicate the info. For example, After you launch the Netscape (default charset is Western (ISO-8859-1), if you go to http://home.netscape.com/ja (Shift_JIS is meta charset), Westerm (ISO-8859-1) in Character coding has check mark. then, if you go to http://home.netscape.com/ko (Korean EUC-KR is meta charset), Westerm (ISO-8859-1) in Character coding menu has still check mark. However, if you shoose the character coding menu from static menu, the check mark will change the menu whatever you choose.

I can only refer to my comment above, from September 15 of last year. While I am sorry to see this defect is still in the product, it does not fit the profile for bugs we can target for 0.9.2. Please feel free to either explain how this is important, or escalate it, or attach a patch for consideration during 'limbo'.

moving off the nsbranch radar. let me know if this is a mistake.

can you mark it nsbranch- instead of removing the nomination? at least we can revisit the nsbranch- for a future release without having to renominate them

I agree with Montse. For future projects it will be great to have the nsBranch marking so we can re-evaluate these bugs. Let's mark with nsbranch-

Yuying, please retest this since this is very old bug.

This one is not reproducible all the time, but it still existing some times at lest on my Mac9.0. I think we better to fix it. So I'd like to keep this open, till we find a good solution for it.

marking as nsbranch-

Cleaning up the Whiteboard.

-> pinkerton. Check if this happens on OS X, if not, I'd say future it

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

over to nhotta who has a patch for i think the very same bug.

Yuying, what are the remaining problems? I fixed the menu checkmark bug 98625 on trunk recently.

It turns out that I can not reproduce this problem on latest build.

Was that check mark problem? If so, this can be dup of bug 98625.

It was check mark problem, but even on recently branch build with Mac OS 9x, I still can not reproduce it any more. So maybe we can resolve it as works for me?

That fine. BTW, please verify bug 98625

Resolve this as works for me.