OS/version: MAC OS 9.0 Build ID: 2000030813M15 Steps to reproduce: 1. Choose QA and smoketest from Netscape 6, and Click International. 2. Select one of Korean URLs links from that page. 3. Choose character coding after clicking view from Netscape 6 menu bar. 4. Set it to Korean . 5. Select one of traditional Chinese URLs links from that page. 6. Set it to Chinese (big5). 7. Select one of Simplified Chinese URLs links from that page. 8. Set it to Chinese GB 2132. 9. Go back view-->character coding Expected result: Four check marks are displayed at the same time on character coding submenu.

cwang: I am very confuse. What is your "expected result" ? What is your "actual result" ? You state that your "expected result" is seeing 4 check mark ? Is that true that is the "actual result" but you are expecting only "one check mark" ?

I stated that "expected result" means "actual result". Pardon me if I didn't do the wording clearly.I saw 4 check marks after I ran the process . Yes, I was expecting only "one check mark" as it should be.

cata- somehow the character set menu display multiple check mark on Mac. Is this a generic Mac menu check mark problem? Or you forget to clean up something. cwang- can you reproduce this on window or Linux ? add hyatt to the cc list and reassign to cata

Works as usual on WinNT and Unix, so it seems to me that it is one of those Mac-specific radio menu problems that keep happening lately. So I am reassigning to our expert in the area. Pink, please take a look at this. The radio menus don't have a "radio" behavior on Mac. Let me know if you need more details.

Reassigning.

sure, i'll look into it. the only thing i can think of is that these items are added w/out the correct name="foo" so the menu code thinks they are in different radio groupings. Other mac radio menus all work, so.....

Here's the template rule used: <rule> <menupopup> <menuitem type="radio" name="charsetGroup" checked="rdf:http://home.netscape.com/NC-rdf#Checked" uri="..." value="rdf:http://home.netscape.com/NC-rdf#Name"/> </menupopup> </rule> It has the "name="...

moving all defects not directly related to P0 beta2 features off to M18.

This is a really ugly usability bug. We wanted bug 11774 fixed for Beta1, but were denied. This character coding menu should provide the user with feedback on what charset is being used to render the page. Definitely need this for beta2, but the sooner the better... Works on Win and Linux.

this is a bug, plain and simple. fixing this would mean critical features would not be implemented by the beta2 feature complete date.

Mass moving M18 bugs to M19

But as bobj said, this is a usability bug. How are users going to know which encoding they are using???

adding nsbeta2 for evaluation

Putting on [nsbeta2+] radar for beta2 fix.

Checked on 2000-05-08-08-M16 comm build. This problems still exists on today's build. It is parity bug only on MAC.

moving back into the realm of beta2

This does not happen in 2000-05-16-11 Mac build. Character coding menu item is not marked once selected. - bug 39312.

This problem never goes away. Browse different language sites, or go to QA-> smoketest via menu bar, test some Intl sites, you will get plenty marks.

OK. I see this problem in 2000-05-18-08 Mac build.

fixed.

Observed on Mac 2000-05-26-08-M16 comm build. It is fixed.

I verified this in 2000-06-02-08 Mac build.