In Composer, Character coding menu is now dynamic one, but the function of it does not work. Steps of reproduce 1. Open Composer 2. Select menu View|Character coding Under Auto-detect submenu, "Western (ISO-8859-1)" submenu is there. 3. Select menu View|Character coding->Multibyte->Japanese (Shift_JIS) 4. Select menu View|Character coding again Actual result Under Auto-detect submenu, only "Western (ISO-8859-1)" submenu is there. Expected result Under Auto-detect submenu, "Western (ISO-8859-1)" submenu and "Japanese (Shift_JIS) are there and "Japanese (Shift_JIS) should be marked. Tested 2000-05-18-08 Mac, Win32, and Linux build.

Nominating this for beta2 since the 38079 (Composer: replace charset menu with dynamic one) was nsbeta2+. 38079 was talking about UI, but this bug is about function.

Reassign to ftang@netscape.com

I don't know if Frank is the right person, thought. Frank, if you need any help please let me know. I have a pretty good understanding of the issues.

somehow the code does not work now. I need to investigate it.

Putting on [nsbeta2-] radar for beta2 fix. msanz believes the is a workwround. Please see her if not the case.

charset menu issue. Is this the same problem as the >=0 but not >0 comparision ? Reassign to cata, cc jbetak

M16 has been out for a while now, these bugs target milestones need to be updated.

I think we could ship nsbeta2 without it. Usually you won't reuse composer window to edit different document.

In build 2000070713 on Win95, the charset menu does nothing. I open a blank page. I changed the menu to SJIS. I pulled down the menu again and it set back to Latin1. I saved it anyway, and it saves an unlabeled HTML page with all the Japanse characters written out as NCRs. This problem has nothing to do with reusing composer for another document. I cannot change the charset using this menu of the first document I edit. This is really really bad.

Ugh, the patch was added by mistake. It belongs to another bug. How can I delete the attachement?

Per today's I18n Beta2 QA Status mtg. All agreed that nsbeta2+ is the way to go. Moving from [nsbeta2-] to [nsbeta2+] Plus(+)to save user inputted charset at a minimal.

why is this nsbeta2+ ? composer window won't got recycle as browser window across section. Why this is important for nsbeta2 ? > Plus(+)to save user inputted charset at a minimal. But this mene is NOT to "save user inputted charset". It is used to change the default viewing charset for a unlabel document.

remove [nsbeta2+]

Ok, after I talked with Frank Tang, I decided to log the different bug about charset coding menu does not put the meta charset info. -45876 (That is the bug nsbeta2+ bug, not this bug.)

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

This is partially working, with the exception of cache. Hence, a check mark will not be displayed. Marking as nsbeta3-.

Adding [nsbeta2-]

Everything on the menu side is done. Now in order to add a charset to cache, one should call the SetCurrentComposerCharset() method. For an example, please take a look at the way it's done for mail and browser in charsetOverlay.js If you need more details, ask me.

Changed QA contact to ylong@netscape.com.

composer problem. Assign to yokoyama mark it as P3 moz 0.9

The Mtrunk build no working as: After you first choose a charset by going View|Character Coding, and then go back View|Character Coding again, there only a grey-out sub-meunu with Western(iso-88591) exists. Is that supposedly be right behavior?

> The Mtrunk build no working as: > After you first choose a charset by going View|Character Coding, and then go > back View|Character Coding again, there only a grey-out sub-meunu with > Western(iso-88591) exists. Is that supposedly be right behavior? No. Under the current spec, if you did not input anything new into the document, you should be able to change the menu as many times as you like. Currently, there seems to be no caching of the menu items (dynamic menu additions) and also there is a bug in disabling the menu. This area probably needs re-thinking and should be revised but the current spec is at the above URL. Even if we revise this spec, it is important that those working in this area understand the current specs.

Change QA contact to Marina.

re-assigning QA contact

Can I ask another question on this one? When you change the character coding in composer, should it change the font to match the one set for the encoding in preferences?

I think this problem is not existing any more by fixed for some other bugs. Currently, the charset also the font will be changed once you select a charset other than default.

This seems work now. Roy, please mark as worksforme.

As requested

Verified.