Build 2001-010504: NT4, Mac 9.04 Build 20001-010410: Linux 6.2 Overview: If I've chosen All Threads Expanded then I would like this option to be remembered. Steps to reproduce: 1. Select the Inbox 2. Select the Threaded icon 2. Select View|Messages|Expand All Threads 3. Switch to another folder 4. Switch back to the Inbox Actual Results: The messages are threaded but collapsed. Expected Results: I would expect them to remain expanded. I would like to see the threads remain expanded: a. after switching between folders b. after closing and opening mail (this is while the browser is always open) c. after quitting and opening mail

Marking nsbeta1 because I use this mode all the time but don't know about the target user.

marking nsbeta1+ and moving to mozilla0.8

moving to mozilla0.9

marking nsbeta1- and moving to future milestone.

Possible short-term workaround - bind a key to View|Messages|Expand All Threads ? Gerv

Is this forgotten? I'd love to have this feature - currently, View by Threads is useless to me.

Gerv: Could you give an example of how to assign a keybinding to this feature, as you allude to in comment #5? Seth: Any progress towards this bug? As Pedro mentions in comment #6, View by Threads isn't very useful to me without Expand All Threads remembering its state (the "on" state, in this case). Asa: Should this bug's "nsbeta1+" Status Whiteboard be transferred to the "nsbeta1+" keyword?

I don't know how to do it exactly, but I do know you can bind keys to any menu item using XUL. Check the XUL reference :-) Gerv

/ and * are currently boudn to collapse and expand respectively.

Timeless: Though a hotkey for Expand All Threads helps a little, it only affects the currently selected folder :-/. Suppose that a user wanted to view every folder as threaded. If Expand All Threads remembered its state, then at least he/she would only have to go through each folder only once (instead of going through each folder every time MailNews is loaded).

i don't care. please let me randomly spam bugs instead of cc'ing me. if i care i'll get the email (in fact, i'll get the email cc or no cc). in comment 5, gerv suggested a workaround (keybindings) in comment 7, you asked about how to implement it in comment 8, gerv said he didn't know in comment 9, i said that keybindings were present. my comments were directed solely at that little mini thread which was something in which you expressed an interest. I really don't care about this bug and shouldn't need to comment further. but to answer your supposition in comment 10, "then i suppose that's the purpose of this bug".

Mail triage team: nsbeta1-

I'll offer a case of beer to anyone that fixes this bug, payable upon checkin to the trunk. I would be happy to send the money by PayPal or to call your local distributor of choice to prepay for the case :).

Taking. But how would you clear this state? By collapsing all?

> Taking. But how would you clear this state? By collapsing all? You mean, what happens when Expand All Threads is turned off? Presumably, that would be through Collapsing All.

See also bug 61331.

fixed as part of work on bug 72493

Reopening. This one appears to have resurfaced. Old threads in a given mailbox remain expanded, but new threads don't appear expanded :-/. (Running 20031218 on Win2k here, though I think I've seen this for a couple days.)

The problem appears also when reordering on a different parameter (date, or subject..), having the essages unthreaded. When you reactive threaded visualization, all threads are expanded.

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

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

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

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

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

Confirming that this bug is still present in current builds (20090614 Shredder/3.0b3pre), particularly the behavior described in comment #18 -- "Old threads in a given mailbox remain expanded, but new threads don't appear expanded" Marking NEW.

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

Returning to NEW as per comment #25. :-) Gerv

comment #25 talks about a different product than this is filed in, but OK, it's probably the same in both UIs. In any case, this is an RFE.

It still exists in SM 2.14.1 - It has been a problem for many years. The status of 'expand all threads' does not remain 'true'. Is there an option in about:config that I can modify?

Well, SM 2.22.1 is out and bug still exists. Time to assign it to one who will work on it in his/her spare time. Not an earthshattering bug, but one that should be fixed. First reported 12 years and 11 months ago.

Reported:2001-01-05 Status: NEW Don't want to be rude but c'mon.. Either reject it or do something about it. This bug is super annoying.