28869 - Feedback of the current charset used by libmime

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect, P3)

Description

[nhottanscp]

When libmime decide a main body charset to use, the charset name to be feed 
backed to the user by putting a mark on the charset menu item.

First we need a way to notify the used charset to webshell from libmime. There 
is a related bug (5938), I will initially assign this bug to mscott.
After that is implemented, libmime can notify the main body charset to webshell.
The UE part (menu check mark) to be done by i18n. Please reassign to nhotta 
then.

Comment 1

[selmer (gone)]

Seems like this should be "IN" for beta2.  Yes?

Comment 2

[Katsuhiko Momoi]

Yes. This is in the spec for Intl Messenger.
Assigned myselsf as QA contact since this is in
Intl area.

Comment 3

[Phil Peterson]

A question about the proposed UI: if we stuff the libmime charset into the
charset menu, how will the user know what the per-folder charset is? Aren't we
losing an important piece of information by reusing the UI?

It also seems strange that the libmime charset is read-only (user can't change
it without changing the message contents), but we're displaying it in read/write
UI of a menu. WHat happens when you change the menu setting?

Comment 4

[nhottanscp]

A folder charset to be specified as a folder property (bug 32714). Since libmime 
honors the charset in the message, usually the user does not have to worry about 
the folder charset but we may want feedback like showing it in the window title.
A folder charset to be used for messages with no charset labels or the user 
wants to force to set a charset to that folder (i.e. ignore the message labels 
and always use the force charset for that folder).
A charset menu is used for per message override (bug 5938). For the message with 
wrong charset message, the user can override it by the menu. To do so, the user 
wants to see what the current interpretation by libmime before changing it to 
something else.

Comment 5

[nhottanscp]

Putting beta2 for i18n beta2 criteria items. Contact bobj for question.

Comment 6

[leger]

Putting on [nsbeta2+] radar for 5/16 work

Comment 7

[leger]

Putting on [nsbeta2-] radar. Removing [5/16]. Missed the Netscape 6 feature 
train.  Please set to MFuture.

Comment 8

[nhottanscp]

this means no check marks for the menu

Comment 9

[bobj]

We need to provide user feedback, otherwise this this would be a horrible
usability problem.  The charset menu will most likely be used when a user
cannot read the current message.  Without knowing what mail is currently using
for the message charset, it will be difficult for the user to determine if
it is using the wrong charset and which one to change it to.

Comment 10

[leger]

What is the scope/impact of taking this now?  Putting on [NEED INFO] radar.

Comment 11

[Scott MacGregor]

I think it would take me about 2 days to implement a solution for this. Is this
what you are looking for when you ask for NEED INFO?

Comment 12

[Peter Trudelle]

[nsbeta2+] will take fix by [6/22]

Comment 13

[scottputterman]

I wanted to comment on phil's comment. Currently the code uses the charset menu
to change the folder charset.  If you haven't already, then you need to take
this out if you want the charset menu to reflect the message's charset.

Comment 14

[nhottanscp]

Scott, you are right. We are keeping it for debugging purpose because we have 
not had the folder charset UI.
Scott (mscott), could you remove it when you check in for this bug?

Comment 15

[Mike]

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

Comment 16

[Jim Roskind]

Cleaning up status whiteboard and marking beta2 minus (6/22 has passed)

Comment 17

[bobj]

Re-nominating nsbeta2. Removed "[FEATURE]" from Summary and assigned to nhotta.

This is really a bug not a feature as indicated in the summary.  This old
bug (filed in Feb.) was erroneously marked a "[FEATURE]" on the basis that
libmime had no way to provide feedback on the message charset.

The character coding menu exists in the browser, message send and message
view windows. But in the message view window it fails to provide feedback
(check mark).

This is a critical usability issue.  The charset menu will most likely be
used when a user cannot read the current message.  Without the check mark
there is no way to provide feedback on the charset being used and assist
the user to take action to correctly view the message. 

Determining the charset during message viewing is different (from the 
browsing) in that the charset does NOT correspond to the displayed HTML
(which is internally generated for messages).  Instead the charset of the
actual message (parsed by libmime) is needed. The fix is to modify libmime
to pass on the charset info, so it can be reflected in the menu. 

Since mscott is doomed, the proposal is to have mscott give a brain dump
to nhotta who will take ownership for fixing this bug.  Earlier (6/2/2000),
mscott estimated 2 days for this.

Comment 18

[bobj]

Forgot to remove "[FEATURE]"...

Comment 19

[bobj]

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

Comment 20

[leger]

Putting on [nsbeta2+] radar.

Comment 21

[nhottanscp]

Backend code is done and to be reviewed by mscott.
For the JS code, I need a help from Cata to make charset menu to work for 
messenger.

Comment 22

[nhottanscp]

There is a remaining problem in charset menu. Currently, there is no way to add 
a charset to a cache for mail view charset menu (bug 45172). So cannot put a 
check mark since a menu item cannot be added.
Cata estimated a half day for that. When his code is ready, I can test with my 
changes and check in since it's actually a part of this bug.

Comment 23

[nhottanscp]

I checked in the backend code. Now the libmime charset is accessible from JS 
code. When the charset menu bug is resolved, I can change the JS code to use 
that charset to put a menu check mark.

Comment 24

[nhottanscp]

Fix checked in.
Here is how the menu gets a check mark.
* If manual override (by menu) or global override (by pref) exists then override 
charset is checked.
* If no override and message main body Content-Type charset is specified then 
that charset is checked. For multipart message, the first message's charset is 
checked.
* If no charset is specified in the message and no override exists then the 
default view charset is checked.
* The result of auto detection is not used. This is because libmime depends on 
line based detection and no simple and efficient way to get that information. 
However, since auto detection is usually applied to attachments and attachment 
charset does not affect menu checkmark, it should not be a problem.

Comment 25

[Katsuhiko Momoi]

** Checked with 7/14/2000 Win32, Mac and Linux builds **

1. MIME-charset exists --> works OK on Win & Linux
2. Existing MIME-charset has been overridden mnauly or
   globally  --> works on Win & Linux
3. No MIME-charset exists --> works OK on Win & Linux

On Mac, there is a problem. The check mark does not get updated
from message to message. This looks like a FE problem. For example,
I sometime see it updated if I come back to the View | Character
Coding menu several times. It generally gets updated if you highlight
any of the charset sub-set menus (without choosing an item within
the subset menu). 

I'm going to mark this bug fix verified and will file a separate
bug for the Mac update problem.