Build: 09-06 Mac trunk build on Mac OS X Steps: 1. Launch browser, make sure auto-detect set to OFF, then go: http://home.netscape.com 2. View | Character Coding, western-iso-8859-1 is marked which is correctly. 3. Go://home.netscape.com/ja - this is a page with x-jis meta-charset. 4. Check the charset by go View | Character Coding: actual resullt: Western-iso-8859-1 is marked expected result: shift-jis should be marked. 5. Reload the page, now shift-jis is marked. 6. Go: http://home.netscape.com/zh/tw which is a page with big5 meta-charset: actual result: Shift-jis is marked. expected result: Big5 should be marked. 7. Reload the page, then Big5 has been marked.

=== assigning to jbetak. Related to charset/menu

hmm, I think I know how to fix this. Yuying can I use your MacOS X installation for testing?

10-02 branch build on Mac9.1-Ja, this problem is exsiting on auto-detect set to both ON (all, Japanese...) and OFF.

moving to 096 - I tried some of my ideas and they have not addressed the issue. I don't have a good fix for this right now.

we might be able to dupe this against bug 102026. Let me try to land that first and see what happens. I'm moving this to M097 otherwise.

Yuying - I just landed a patch for bug 102026. I'm marking this as a dupe of said bug since there is a good chance that this will work. Please reopen if that's not the case. *** This bug has been marked as a duplicate of 102026 ***

Sorry, I still see this on today's (11-14 trunk) build / Mac OS 10.1.

OK then - I really don't know how to resolve this. We should give it to some XPFE people since there seem to be some Mac-OSX-specific issues with our XUL widget set.

jbetak's contract is up. Bulk move bugs to ftang

give to nhotta for M0.9.7 P2.

Nominate as nsbeta1 - it confuse user.

nsbeta1+ per i18n triage

move to ftang

assign

interesting, if I clock on the menu in step 4 it show me ISO-8859-1 but if I do not rlease mouse, move up to "Languages and Web Content" and move back again, it show me "Shift-jis" this must related to some timing issue. cc rchen and xyia

same as what Frank said, to make it clear: 1) Goto netscape.com US page, click View menu, "Character coding" shows "western-iso-8859-1". 2) Then goto netscape.com JA page, JA characters show properly. 3) Then, the first time to click on View menu, "Character coding" always shows "western-iso-8859-1", but from the second time clicking on the menu, "Character coding" will stay on "Shift-JIS". I think this should be the menu refresh problem.

In another word, the problem is, after you goto another language page, that page's encoding will be added into the "Character Coding" list on the menu, but just without the check mark refresh.

looks like it caused by 78290

ylong- can you verify this still on mac os 9 or not ?

Impact Summery Impact Platform: MacOS X only Impact language users:All internet users100% Probability of hitting the problem:Minor work flow, depend on both user's action and incoming data. Severity if hit the problem in the worst case: Confuse users Way of recover after hit the problem: Look at that menu again Risk of the fix: Unknown Potential benefit of fix this problem: Fix other MacOS X menu issues if there are any

> Impact language users:All internet users100% i'd venture a guess that perhaps 5% of our users even look at the charset menu, and of that, maybe 1% can explain what it should be doing. I don't think this affects 100% of internet users by any stretch of the imagination.

〉ylong- can you verify this still on mac os 9 or not ? It's on OS X. Yes, still see the problem, however it turns on latast trunk build, some times see it some times not, before I saw it all the time.

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

nhotta, please help me to look at this one. I am very busy right now for the mac embedding IME problem. Thanks

reassign back to ftang

really need help. Have no clue how to sovle this problem now.

One thing I realized is that UpdateMenus(event) which sets attribute 'checked' for the menu is called onpopupshowing. I think it should be onpopupshown because we need to let the menu construction to complete. 224 <menu id="charsetMenu" label="&charsetMenu.label;" accesskey="&charsetMenu.accesskey;" datasources="rdf:charset-menu" ref="NC:BrowserCharsetMenuRoot" oncommand="MultiplexHandler(event)" onpopupshowing="CreateMenu('browser');UpdateMenus(event)" onpopupshown="CreateMenu('more-menu');"> http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/charsetOverlay.xul#224 But it does not work. I changed to onpopupshown="UpdateMenus(event);CreateMenu('more-menu');" but no check mark appeared, it appeared after I hold down the mouse and visit other menu items (same as the comment #15).

reassign to nhotta. sorry, I don't have time to deal with this now. can you take a look at this one again ?

This is not MacOS X only, I was able to reproduce using classic build on OS 9. I found that the checkmark is not always incorrect. I mean, sometime it check marks to the correct charset.

The menu attribute is set by JS. 136 menuitem.setAttribute('checked', 'true'); http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/charsetOverlay.js#136 Then the Mac menu code is called and get the attribute. 853 inMenuItemContent->GetAttr(kNameSpaceID_None, nsWidgetAtoms::type, type); http://lxr.mozilla.org/seamonkey/source/widget/src/mac/nsMenuX.cpp#853 But the problem is GetAttr in the Mac code does not get the new value set by the JS code.

One thing I found is that there is a point that more than one menu item have checked state for the menu. In nsMenuX::OnCreate, the dom event is executed and the new menu item is checked in onpopupshowing. After that, it is possible to have two menu item have checked state. When nsMenuX::LoadMenuItem is called to actually check mark the menu widget, there is only one menu item checked. However, the checked item may not be the one which was checked by the dom event. It seems like always the first checked item is remain checked. For example, if item 1 was checked before and item 3 is now checked by dom then item 1 is still checked and no check for item 3. I think this explains the randomness of this bug. When the new item is above the currently check item then the check mark is set to the new item correctly. But when the new item is below the current item then the new item is not checked.

Mike, could you review the patch?

there is code in nsMenuItemX that unchecks radio menus when the checked attribute is set (UncheckRadioSiblings()). as far as i can tell, it works. the two things that would confuse it are if the items aren't type radio or if they're not in the same group (have the same |name| attribute). could either of these be the case? you shouldn't have to write this code yourself since it's already there in the menu code.

nhotta: can you set a break point at (UncheckRadioSiblings()). and see it will be executed or not. pinkerton: will it work with menu item generated by RDF template ?

i don't see why it being a template should matter. the items need to be of type radio and all have the same group name. that's the only restriction.

I set a break point at UncheckRadioSiblings and it is called indirectly from nsMenuX::LoadMenuItem (by nsMenuItemX::SetChecked). But it is not called for the setAttribute JS call in onpopupshowing. As I wrote in comment #31, the SetChecked call in nsMenuX::LoadMenuItem already got an incorrect item to set. I think the siblings need to be unchecked after onpopupshowing and before LoadMenuItem.

>the siblings need to be unchecked after onpopupshowing and before LoadMenuItem. nsIMenuItem is created at nsMenuX::LoadMenuItem, so there is no way to call nsMenuItemX::UncheckRadioSiblings before LoadMenuItem. And the 'check' attiribute is already incorrect at LoadMenuItem...

Now I have a question. Who is supposed to maintain 'checked' attribute for radio type, content or widget?

the siblings (content nodes, not menu items) are unchecked from the attribute changed event that is sent when you check the menu item.

>Now I have a question. Who is supposed to maintain 'checked' attribute for radio type, content or widget? content.

Comment on attachment 85829 [details] [diff] [review] Uncheck the previously checked item before checking the new item to workaround the Mac check mark problem. r=pink.

Comment on attachment 85829 [details] [diff] [review] Uncheck the previously checked item before checking the new item to workaround the Mac check mark problem. sr=jst

checked in to the trunk

can iqa verify this by this week?

Verified fixed in 06-14 OS X trunk build.

change this bug from assign to fixed and verified base on the comment eariler.

please also verify other platform do not have bad side effect by this check in.

adding adt1.0.1- per ADT.

Mark as verified per comment #46.

Removing the item for this bug from the release notes for 1.1beta and beyond.