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.
Seems like this should be "IN" for beta2. Yes?
Yes. This is in the spec for Intl Messenger. Assigned myselsf as QA contact since this is in Intl area.
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?
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.
Putting beta2 for i18n beta2 criteria items. Contact bobj for question.
Putting on [nsbeta2+] radar for 5/16 work
Putting on [nsbeta2-] radar. Removing [5/16]. Missed the Netscape 6 feature train. Please set to MFuture.
this means no check marks for the menu
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.
What is the scope/impact of taking this now? Putting on [NEED INFO] radar.
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?
[nsbeta2+] will take fix by [6/22]
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.
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?
M16 has been out for a while now, these bugs target milestones need to be updated.
Cleaning up status whiteboard and marking beta2 minus (6/22 has passed)
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.
Forgot to remove "[FEATURE]"...
*** Bug 43915 has been marked as a duplicate of this bug. ***
Putting on [nsbeta2+] radar.
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.
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.
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.
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.
** 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.