Closed Bug 46362 Opened 24 years ago Closed 24 years ago

Character coding menu not effective in correcting non-MIMe encoded headers in thread pane

Categories

(MailNews Core :: Internationalization, defect, P3)

Product:
MailNews Core
Component:
Internationalization
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: momoi, Assigned: nhottanscp)

References

Details

Attachments

(1 file)

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
Details 
** 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.
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
Keywords: nsbeta2
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
Keywords: nsbeta2
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
Closed: 24 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.
Product: MailNews → Core
*** Bug 287786 has been marked as a duplicate of this bug. ***
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: