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

NEW
Unassigned

Status

SeaMonkey
MailNews: Message Display
15 years ago
7 years ago

People

(Reporter: Felix Miata, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: see comment 8 and comment 16 for details)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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

15 years ago
Not Os/2 specific
OS: OS/2 → All
Hardware: PC → All

Updated

15 years ago
QA Contact: olgam → laurel
Blocks: 176238

Comment 2

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

Comment 3

15 years ago
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

15 years ago
Created attachment 116185 [details]
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.
(Reporter)

Comment 5

15 years ago
Created attachment 116191 [details]
Screenshot showing only 3 of 6 total BCC addresses in XUL headers

What theme is that? I only use modern.

Comment 6

15 years ago
> 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

15 years ago
Felix, could you test this thing again, taking my comment 6 in account?
(Reporter)

Comment 8

15 years ago
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.
Summary: Incomplete BCC list displayed using "all" for view - > headers → Incomplete CC & BCC lists displayed using "all" for view - > headers

Comment 9

15 years ago
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

15 years ago
Created attachment 118346 [details] [diff] [review]
proposed patch
(Reporter)

Comment 11

15 years ago
 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

15 years ago
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

15 years ago
Created attachment 118409 [details] [diff] [review]
beautify proposed patch

changed style according to original code
Attachment #118346 - Attachment is obsolete: true

Comment 14

15 years ago
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

15 years ago
Created attachment 118652 [details] [diff] [review]
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.
(Reporter)

Comment 16

15 years ago
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.
Product: Browser → Seamonkey

Updated

13 years ago
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: laurel → message-display

Comment 17

9 years ago
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
Status: NEW → UNCONFIRMED

Comment 18

9 years ago
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

9 years ago
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

8 years ago
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → EXPIRED

Comment 21

7 years ago
Still valid and reasonable, see comment 8 and comment 16 for details.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: EXPIRED → ---
Whiteboard: see comment 8 and comment 16 for details

Updated

7 years ago
Status: REOPENED → NEW
You need to log in before you can comment on or make changes to this bug.