39780 - Dynamic character coding menu does not work in Composer

Status: VERIFIED WORKSFORME

(Core :: Internationalization, defect, P3)

Description

[Teruko Kobayashi]

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.

Comment 1

[Teruko Kobayashi]

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.

Comment 2

[Teruko Kobayashi]

Reassign to [e-mail]

Comment 3

[cata]

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.

Comment 4

[Frank Tang]

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

Comment 5

[leger]

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

Comment 6

[Frank Tang]

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

Comment 7

[Mike]

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

Comment 8

[Frank Tang]

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

Comment 9

[bobj]

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.

Comment 10

[cata]

Attachment: Proposed patch.

Comment 11

[cata]

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

Comment 12

[leger]

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.

Comment 13

[Frank Tang]

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.

Comment 14

[Frank Tang]

remove [nsbeta2+]

Comment 15

[Teruko Kobayashi]

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.)

Comment 16

[Jay Patel [:jay]]

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

Comment 17

[Frank Tang]

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

Marking as nsbeta3-.

Comment 18

[leger]

Adding [nsbeta2-]

Comment 19

[cata]

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.

Comment 20

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 21

[Frank Tang]

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

Comment 22

[Yuying Long]

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?

Comment 23

[Katsuhiko Momoi]

> 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.

Comment 24

[Yuying Long]

Change QA contact to Marina.

Comment 25

[marina]

re-assigning QA contact

Comment 26

[Mike Kaply [:mkaply]]

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?

Comment 27

[Yuying Long]

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. 

Comment 28

[Teruko Kobayashi]

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

Comment 29

[Roy Yokoyama]

As requested

Comment 30

[Yuying Long]

Verified.