Open
Bug 171442
Opened 22 years ago
Updated 14 years ago
Incomplete CC & BCC lists displayed using "all" for view - > headers
Categories
(SeaMonkey :: MailNews: Message Display, defect)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
NEW
People
(Reporter: mrmazda, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: see comment 8 and comment 16 for details)
Attachments
(4 files, 1 obsolete file)
5.43 KB,
image/png
|
Details | |
55.76 KB,
image/png
|
Details | |
1.70 KB,
patch
|
Details | Diff | Splinter Review | |
4.22 KB,
patch
|
Details | Diff | Splinter Review |
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 2•21 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•21 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•21 years ago
|
||
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•21 years ago
|
||
What theme is that? I only use modern.
Comment 6•21 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.
Reporter | ||
Comment 8•21 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•21 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•21 years ago
|
||
Reporter | ||
Comment 11•21 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•21 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•21 years ago
|
||
changed style according to original code
Attachment #118346 -
Attachment is obsolete: true
Comment 14•21 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•21 years ago
|
||
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•21 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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•19 years ago
|
Assignee: sspitzer → mail
Updated•16 years ago
|
Assignee: mail → nobody
QA Contact: laurel → message-display
Comment 17•15 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•15 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•15 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•14 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
Closed: 14 years ago
Resolution: --- → EXPIRED
Comment 21•14 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•14 years ago
|
Status: REOPENED → NEW
You need to log in
before you can comment on or make changes to this bug.
Description
•