171442 - Incomplete CC & BCC lists displayed using "all" for view - > headers

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Felix Miata]

2002092808 OS/2 trunk; 1024 x 768

As in bug 118899, this is another instance of hiding headers displayed by 4.x.
View message source displays them all, but that's the only way, and more trouble
than it has compelling reason to be.

To reproduce:
1-set message display to show all headers
2-compose a message with more than three BCC recipients
3-send
4-select sent message folder
5-select the just sent message
6-collapse the folders pane

Actual behavior:
1-BCC list shows no more than three recipients

Expected behavior:
1-BCC list shows all recipients, wrapping to as many lines as is required to fit

Comment 1

[Mike Kaply [:mkaply]]

Not Os/2 specific

Comment 2

[Christian Eyrich]

> Actual behavior:
> 1-BCC list shows no more than three recipients

That's not true at least for 20030228 on Linux.
3 BCCs are shown, more optionally via triangle switch.

Doesn't this behaviour solve this bug?

Comment 3

[Felix Miata]

In Linux 2003030308, OS/2 2003030212 and W32 2003022408, just as when reported
in Sept, no more than 3 BCC's can be seen except via view->message source or
using a file viewer on the sent file..

Comment 4

[Christian Eyrich]

Attachment: Screenshot showing more than 3 BCC

That's interesting. I now tested it with rv:1.3b/2003011508 on Win98 with same
result as my previous test. See Screenshot attached.

Comment 5

[Felix Miata]

Attachment: Screenshot showing only 3 of 6 total BCC addresses in XUL headers

What theme is that? I only use modern.

Comment 6

[Christian Eyrich]

> What theme is that? I only use modern.

Me too.

> Screenshot showing only 3 of 6 total BCC addresses in XUL headers

Eh, yes it does. But are you sure you never expanded the BCC-line by clicking
the triangle in front of them? Your screenshot shows it collapsed.

Comment 7

[Christian Eyrich]

Felix, could you test this thing again, taking my comment 6 in account?

Comment 8

[Felix Miata]

Yes, the twisty can be used to make the others display, but the first screenshot
is "normal" headers, while the second is "all" (per this bug's summary). So,
there are at least two problems currently: 

#1-Per summary, the menu selection is: view -> headers -> all, not view ->
headers -> some (or mostly or selected or all except ...)
#2-There is no twisty for newsgroups. Four or more newsgroups are always shown
in either all or normal view. CC, BCC and newsgroups should work the same (be
consistent), either all should have twisties or none should have them.

I noticed in my single testing session today that the twisties stick. That is,
they behave as a preference, staying open or closed as last selected even when
switching among messages.

I can understand the use of twisties for normal view, but don't find it
acceptable for all view.

Comment 9

[Christian Eyrich]

Ah, ok, now. I understand what you want.

#1 I really think it's a matter of taste or how to understand the feature.
Selecting view -> headers -> all results in display of all header fields though
not all members of all fields.

Did you know, you can adjust the number of addresses to show without a twister
via mailnews.max_header_display_length?
Although I must admit that this affects both header views, all and normal.

I just made some changes to the code so all e-mail addresses (to, cc and bcc)
are displayed when in all header mode.
But we should talk about the behaviour to the module owner or peers first
because it's a matter of taste as I wrote.

#2 ACK, this should be consistent. Adding a twister to the newsgroups fields is
much more complicated than #1, but maybe I also can to it.
But I think we should file a separate bug for it as it's a different issue.

Comment 10

[Christian Eyrich]

Attachment: proposed patch

Comment 11

[Felix Miata]

 Re: mailnews.max_header_display_length -  how is it used? IOW, how can I make
it default to all for all recipients? 0? -1?

If your patch is as you describe, it should fix this bug. How do we get the
attention of the owner and/or peers, Moznet? I don't seen an obvious nick for
this bug's owner currently on #mozilla. 1.4a branch is due in a matter of hours.

Comment 12

[Christian Eyrich]

Set mailnews.max_header_display_length either to -1 or a very high value (255 or
so). To set it you've to edit the prefs.js in your profile folder. Or you use a
recent build (1.3 should do it I think) and have access to it via the URI
about:config in the browser window.

To get the attention I can ask for reviewing the bug. But first I've send a
request for comment to netscape.public.mozilla.mail-news usegroup. So maybe it
will be a little discussion there.

I think the branching is to near to get the patch landed in any case. Cause
review and super-review needed first.

Comment 13

[Christian Eyrich]

Attachment: beautify proposed patch

changed style according to original code

Comment 14

[Christian Eyrich]

At the moment a little discussion in newsgroup shows, that some people would
prefer to get all e-mail addresses in all header mode by default, but have an
twisty to collapse them further on.

That would result in two memories for the twisty, one for expanded and one for
collapsed view.

What about this?

Comment 15

[Christian Eyrich]

Attachment: alternative patch

According to some users wish a version that keeps the twisty in all header view
but have it expanded by default.
So we've two independent twisty states now, one for all header and one for
normal header view. They're gonna exchanged by need in new method
exchangeToggleIcon.

Not beautiful but passed my tests.

Comment 16

[Felix Miata]

I would rather not have a twisty in "all" view. That would make the menu more
closely match the behavior. I like the 118409 patch better.

Comment 17

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 21

[Karsten Düsterloh]

Still valid and reasonable, see comment 8 and comment 16 for details.