Open Bug 64426 Opened 24 years ago Updated 8 years ago

Expand All Threads to remember its state

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: nbaca, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [nsbeta1+ 2/13]) 

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.
Keywords: nsbeta1
QA Contact: esther → nbaca
Summary: Expand All to remember it state → Expand All to remember its state
Summary: Expand All to remember its state → Expand All Threads to remember its state
marking nsbeta1+ and moving to mozilla0.8
Priority: -- → P3
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.8
moving to mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
marking nsbeta1- and moving to future milestone.
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [nsbeta1+] → [nsbeta1+ 2/13]
Target Milestone: mozilla0.9 → Future
Possible short-term workaround - bind a key to View|Messages|Expand All Threads 
?

Gerv
Keywords: nsCatFood
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-
Keywords: nsbeta1-
Keywords: 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?
Assignee: sspitzer → bienvenu
> 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
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
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.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 236849
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.
Product: Browser → Seamonkey
Assignee: bienvenu → mail
Status: REOPENED → NEW
Priority: P3 → --
QA Contact: nbaca
Target Milestone: Future → ---
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
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.
Status: UNCONFIRMED → 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
Status: NEW → UNCONFIRMED
Returning to NEW as per comment #25. :-)

Gerv
Status: UNCONFIRMED → NEW
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.
Severity: normal → enhancement
OS: Windows NT → All
Hardware: x86 → All
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.
Flags: needinfo?(mail)
You need to log in before you can comment on or make changes to this bug.