Open Bug 346603 Opened 18 years ago Updated 2 years ago

Remove ‘message headers’ menu option in View menu

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: u81239, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5

Hi,

There is an option in the View menu, called ‘message head lines’ (roughly reverse-translated from Dutch :)). This option offers the choice between ‘All’ and ‘Normal’.

I’d like for this option to be removed. Why? Because nobody uses the ‘All’ option, as 1. the message content is pushed off the screen, with most email containing tons of headers, and 2. these headers convey little interesting information (and even if they did, by the sheer amount of them one would not be able to quickly spot the interesting ones).

Also, there is still the ‘message source’ option to view this information (which is actually what I am using whenever I need to look at the headers, I don’t need it thrown in my face permanently).

What would be nice to have is a ‘Properties’ window for email messages, but that is a different bug.


~Grauw

Reproducible: Always

Steps to Reproduce:
1. Start Thunderbird
2. Select View / Message Head Lines / All
3. Browse around in your mailbox

Actual Results:  
You can’t read your messages anymore.

Expected Results:  
You can’t read your messages anymore (the option shouldn’t be there in the first place :)).
This is basically a dupe of bug 154712, which is WONTFIX for the suite...
But this is ‘no nonsense Thunderbird’, not the Suite :).

The feature has serious usability problems (it’s not usable), and is thus useless to the user.


~Grauw
> But this is ‘no nonsense Thunderbird’, not the Suite :).

This is the _only_ reason why this bug is still open...

> The feature has serious usability problems (it’s not usable)

Erm: you wrote:

> Because nobody uses the ‘All’ option

Wrong. _You_ don't (obviously).

> these headers convey little interesting information

Wrong.

There's admittedly problems with this view mode, but it has its place.
(I'm not going to repeat this discussion all over, my focus is the suite. But you should read it. It's EOD for me here.)

> is thus useless to the user.

Wrong.
(In reply to comment #3)
> > The feature has serious usability problems (it’s not usable)
> 
> Erm: you wrote:
> 
> > Because nobody uses the ‘All’ option
> 
> Wrong. _You_ don't (obviously).

For stated reasons.

Email has a lot of headers. It may be that there is mail from a few senders, clients or lists who are sparse with adding headers, but that is generally not the case, and because when this function is on 99% of the email messages are unreadable, there is no practical use.


> > these headers convey little interesting information
> 
> Wrong.
> 
> There's admittedly problems with this view mode, but it has its place.
> (I'm not going to repeat this discussion all over, my focus is the suite. But
> you should read it. It's EOD for me here.)

As useless as it is in its current state, it should not remain there. Take it out, and if the problems are fixed it can be put back in after careful review of what value it actually adds.

Making the headings area scroll along with the text is not a solution to the *real* problem of this functionality; the usability problems of always having to scroll down and the overload of information remain, and thus it will still not be used.

On top of that, it is trivial to add this functionality as an extension.

As for making this functionality do the job it actually needs to do: what about creating a header whitelist functionality instead?


~Grauw
Also, I’d appreciate some politeness. Thank you.
Karsten strongly defends this not-really-useful feature because he has written a nice extension (Mnenhy) that will stop working if the feature goes away.  He has never, however, acknowledged that the proper way to address this problem is to fix the backend code so that his extension can get access to all the headers for a message without having to display them all.

There are some people who don't use Mnenhy but still want to view all the headers for whatever purpose.  Bug 224374 is about allowing the user to pick specifically which headers are shown, presumably handled in Options rather than the clumsy menu setting currently in use; that would address the needs of a large subset of these people (most of whom, for instance, don't need to see the Received headers for every message, but only want to view a certain subset).

View|Source generally will display every single header, altho it does need to be performed for each message and opens into a separate window -- and the View Source window is a bit buggy and could use more features (especially regarding control over encoding display for message body and headers).
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: Remove ‘message head lines’ menu option in View menu → Remove ‘message headers’ menu option in View menu
Version: unspecified → Trunk
I think I tried to remove this once before and wasn't successful at it. I too would like to remove the menu items and instead set a back end pref to make sure extensions have access to all of the headers via the message header sink.
Assignee: mscott → nobody
I do not want to break extensions that rely on this however I think it's completely reasonable to remove this menu item.  The small scroll area for all headers is confusing and length of headers in most mails will drift the other actions button out of the visible area.  We also now have "View Source..." in the other actions of the headers area so the source of the message is easily accessible.

Can someone file a separate bug for implementing the technical parts needed to make extensions like Mnenhy work without this.  Just make a note of the bug in this one.  Thanks.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.