A mailbox file (.zip) which contains msgs without MIME-encoding of headers but body text has proper MIME charset info
2.01 KB, application/x-compressed
** Observed with 7/24/2000 Win32 build ** Not too long ago this function was working. It has been working since since before Pr1, but now I noticed with the above build that it is not possible to correct headers which are not MIME-encoded. This type of problem occurs often in newsgroups and some language mail messages. To summarize: 1. View Default character coding does not seem to apply to non-MIME encoded headers even if the encoding matches. 2. Changing the Character coding menu does not seem to be effective.
Created attachment 11869 [details] A mailbox file (.zip) which contains msgs without MIME-encoding of headers but body text has proper MIME charset info
We really want this to work for Japanese and other languages. nominating for nsbeta2. It was working at PR1, M16 and until quite recently. This is a major regression.
Severity: normal → critical
Is this for message header envelop view? There is a bug filed for that. 43389 Ja chars in the envelope of mails without MIME header are garbled even with right charset selection
There is also a similar bug already filed. 41125 Non-MIME-encoded headers do not display correctly with the view default charset
No, this one is about the thread pane display. For some reason, we are not able to correct headers without any MIME charset info by changing the Character coding menu any more. We were able to do this not too long ago.
Charset menu should only be used for per message override. The menu should not be used to change thread pane view (so PR1 behavior was not what we wanted). Thread pane view should be controlled by a default view charset pref.
So I think this is not really a regression since thread pane view is not controlled by charset menu anymore unlike PR1.
That does not seem right. There is an essential meaning to changing the charset menu, which is "Changing a charset menu" is an instruction to "load a document or message" using that encoding as the source charset. This is a consistent meaning given to charset action throughtout Mozilla. If you do this on a message which has a MIME charset, then that would be a case of override. But if you do this on a message without MIME charset, then that is a case of re-loading with a different charset assumption.
My point is not the meaning of changing charset menu but linking the menu with thread pane view.
From a user-level point of view, why not? Should I not be able to view headers without MIME-charset by changing the menu?
>Should I not be able to view headers without MIME-charset by changing the menu? yes for message body view and header envelop view no for thread pane This bug is about the thread pane view.
We should use default charset for non MIME header view for thread pane regardless of the issue of the charset menu. Momoi san, if you want to keep this bug to discuss about the charset menu issue then we want to file a separate bug for the default charset issue.
Filed a separate bug 46542 to use the default charset for thread pane view. Removing [regression] from subject and nsbeta2 keyword. Target milestone to future.
Status: NEW → ASSIGNED
Summary: [regression] Character coding menu not effective in correcting non-MIMe encoded headers → Character coding menu not effective in correcting non-MIMe encoded headers
Target Milestone: --- → Future
Change the summary to include "thread pane".
Summary: Character coding menu not effective in correcting non-MIMe encoded headers → Character coding menu not effective in correcting non-MIMe encoded headers in thread pane
*** Bug 56685 has been marked as a duplicate of this bug. ***
Severity: critical → normal
OS: Windows NT → All
Hardware: PC → All
Target Milestone: Future → M23
Changed the summary, charset menu not supposed to affect thread pane, charser override in pref (and folder attribute in future bug 32714) should affect thread pane.
Summary: Character coding menu not effective in correcting non-MIMe encoded headers in thread pane → Character override not effective in correcting non-MIMe encoded headers in thread pane
From the user's point of view, this behavior is not very good. I believe that this is one of the major reasons why some Japanese users recently commented that mail is usable for Japanese but not news. In 4.x, we were able to change the display of both thread pane and envelope with a menu change action. I think we should do the same for current display of thread pane headers. One idea is to make it so that the menu change is not permanent and affects only non-labeled headers until another menu change. Incorrectly labeled headers will be corrected again (to an incorrect display) when that msg is reloaded.
I'm saying that even if in future we can have a folder charset, the menu change action should have a limited beneficial effect that users expect. The current behavior is not user-friendly.
Restore the summary based on Momoi san's comment.
Summary: Character override not effective in correcting non-MIMe encoded headers in thread pane → Character coding menu not effective in correcting non-MIMe encoded headers in thread pane
My current plan for folder charset UI is to add the menu item above Character Coding menu item, in View menu. So folder charset override can be discovered easily.
Thread pane will use folder charset attribute (bug 32714). The charset menu change will not affect the thread pane. I mark this bug as wontfix.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX
I hesitate to verify this bug as a duplicate of Bug 32714. A nice thing about the menu change affecting the thread-pane display is its simplicity. From the user's point of view, you change the encoding and it affects the thread pane, message envelope and the message body itself. In the per folder encoding way, you can change the message body and possibly message envelope but not the thread pane view. On the other hand, what I am suggesting here also has some problems. For example, given the meaning of menu change action, it would have to override the charset labels in the body and it has to be a one-time action. Thus, we have less than ideal UI in this proposal or for the per folder charset method. In the per folder case, how does the user ever discover that changing the folder encoding affects the thread pane display. Perhaps we can improve on this by having a menu that says correct the folder pane display under the View menu. Let's think of usability issue in the other bug. Marking it verified as a duplicate.
Status: RESOLVED → VERIFIED
Sorry, verified as Wontfix.
*** Bug 287786 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.