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

VERIFIED WONTFIX

Status

MailNews Core
Internationalization
P3
normal
VERIFIED WONTFIX
18 years ago
10 years ago

People

(Reporter: Katsuhiko Momoi, Assigned: nhottanscp)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
** 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.
(Reporter)

Comment 1

18 years ago
Created attachment 11869 [details]
A mailbox file (.zip) which contains msgs without MIME-encoding of headers but body text has proper MIME charset info
(Reporter)

Comment 2

18 years ago
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
(Assignee)

Comment 3

18 years ago
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
(Assignee)

Comment 4

18 years ago
There is also a similar bug already filed.
41125 Non-MIME-encoded headers do not display correctly with the view default 
charset
(Reporter)

Comment 5

18 years ago
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.
(Assignee)

Comment 6

18 years 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.
(Assignee)

Comment 7

18 years ago
So I think this is not really a regression since thread pane view is not 
controlled by charset menu anymore unlike PR1.
(Reporter)

Comment 8

18 years ago
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. 
(Assignee)

Comment 9

18 years ago
My point is not the meaning of changing charset menu but linking the menu with 
thread pane view.
(Reporter)

Comment 10

18 years ago
From a user-level point of view, why not?
Should I not be able to view headers without MIME-charset by changing the menu?

(Assignee)

Comment 11

18 years ago
>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.
(Assignee)

Comment 12

18 years ago
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.

(Assignee)

Comment 13

18 years ago
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
(Assignee)

Comment 14

18 years ago
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
(Assignee)

Comment 15

18 years ago
*** Bug 56685 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Severity: critical → normal
OS: Windows NT → All
Hardware: PC → All
Target Milestone: Future → M23
(Assignee)

Comment 16

18 years ago
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
(Reporter)

Comment 17

18 years ago
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.
(Reporter)

Comment 18

18 years ago
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.
(Assignee)

Comment 19

18 years ago
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
(Assignee)

Comment 20

18 years ago
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.
(Assignee)

Comment 21

18 years ago
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
(Reporter)

Comment 22

18 years ago
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
(Reporter)

Comment 23

18 years ago
Sorry, verified as Wontfix.
Product: MailNews → Core

Comment 24

13 years ago
*** 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.