325252 - Threads always expanded when returning to folder/newsgroup with MailView (e.g. Unread)

Status: RESOLVED DUPLICATE of bug 1807063

(Thunderbird :: Mail Window Front End, defect)

Description

[RenegadeX]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Thunderbird 1.5 (Windows/20051201)

In the View->Messages->'Unread' view (same as 'Unread' in the dropdown), when returning to a mail folder or newsgroup that had threads 'Collapsed', all threads are automatically expanded.

However, if a user is in the (Messages)'All' view, threads retain their previous setting (be it collapsed or expanded) when the folder/group is returned to.

Reproducible: Always

Steps to Reproduce:
1. Go to a mail folder or newsgroup that you know contains replies as we will be testing Threading.
2. Ensure 'Sort by' is set to Threaded (sort by field, ascending/descending, settings etc are irrelevant).
3. Set View->Messages to 'Unread' (or select 'Unread' in the View dropdown).
4. Set Threads->All
5. Set Threads->'Collapse All Threads'. Observe a '+' sign next to collapsed threads.
6. Switch to a different folder or newsgroup, then return.
7. Observe that all threads are expanded.
8. Change the View dropdown to 'All' (or View->Messages->All). Repeat test, and observe that collapsed threads remain collapsed when returning to the folder/group.



Expected Results:  
Thunderbird should restore the folder/newsgroup to the same view settings as last used, as it does for the 'All' view.

This is likely an 'All/All' .. though I am PC/WinXP.

Comment 1

[Mike Cowperthwaite]

Reproduced TB 2a1-0604.  
Not just 'Unread' -- any MailView will behave the 
same.  Also, using   View | THREADS | Unread   behaves the same -- but
  View | Threads | Threads With Unread   maintains the expand/collapse status (excepting the well-known problem at bug 139242).

Comment 2

[Wayne Mery (:wsmwk)]

exact opposite of bug 319007 behavior

Comment 3

[Wayne Mery (:wsmwk)]

didn't intend to dupe - sorry for bugspam.

Comment 4

[Wayne Mery (:wsmwk)]

Mike, RenegadeX, do you see this with current trunk?
(perhpas this was also happening in SM?)

WFM imap and news
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090118 Shredder/3.0b2pre

Comment 5

[RenegadeX]

(In reply to comment #4)
> Mike, RenegadeX, do you see this with current trunk?
> (perhpas this was also happening in SM?)

I uninstalled Thunderbird years ago, but just reinstalled it with latest nightly so I could answer your question. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090118 Shredder/3.0b2pre

... Behaviour observed in newsgroups is:
A) with View -> Threads -> "Unread", doing Threads -> Collapse all threads, collapses all threads in the current view. Switching to another newsgroup, all threads in this group are *expanded* (which is fine if they were left that way). But when I switch back to the original newsgroup, I find that all threads in this group are now *expanded* -- even though I'd last left them collapsed.

B) Continuing from there, if (while still in that same newsgroup) I then go view View -> Threads -> "All", all threads for that group appear, *collapsed*.

This is not 'correct' behaviour, IMHO, as I had last told Thunderbird to EXPAND all threads, and furthermore, I'd never told it to collapse my threads while in the 'Threads->All' view.

C) Continuing from there (so I'm on View->Threads->"All" with all threads collapsed), if I switch to another newsgroup (.. that group will appear fully expanded), and then switch back, all threads in the original group continue to be collapsed EXCEPT for the thread which was last being viewed -- the last viewed message is in fact selected, and its thread (and only its thread) is expanded.

In this instance, it's not actually a bad way of doing things; however just because a post marked 'read' won't be available to be selected in an 'unread' view doesn't mean the whole thread collapsing behaviour for the group should be different!

D) If I try switching between "View->Threads->Unread" and "View->Threads->Threads with Unread", collapsing threads in one view before switching to the other, the threads in the group will ALWAYS re-expand without being asked to.

Incidentally, I can't notice any difference whatsoever between "Theads->Unread" and "Threads->Threads with Unread", and on the face of it the 2nd name is redundant. But I guess that's for another bug...

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to comment #4)
> Mike, RenegadeX, do you see this with current trunk?
> (perhpas this was also happening in SM?)
> 
> WFM imap and news
> Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090118
> Shredder/3.0b2pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090121 SeaMonkey/2.0a3pre - Build ID: 20090121000535

Yes I do, in a subfolder of Local Folders:
- "View => Messages => Unread" expands everything
- After hitting \ (Collapse all threads) then going back and forth to another folder, all threads are expanded zgain. On reentering the "unread threads" folder, it takes a noticeable fraction of a second for the threads to expand.
- Then, "View => Messages => All" restores the collapsed view.

Comment 7

[dave.nicholls]

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9

I see this hasn't been touched for a long time.  I am still seeing the problem in Thunderbird and in particular it's search folders rather than all news folders that always have the threads expanded when opened/selected.

Comment 8

[Sam Hasler]

Please could the keyword ux-control be added to this bug.

Comment 10

[Wayne Mery (:wsmwk)]

This still occurs, per RenegadeX (who no longer used TB, ditto Sam)

" the results of my originally posted test steps are not exactly as they once were, my originally reported complaint is still valid. Here’s what I did to prove this:

1. I subscribed to 2 newsgroups (“NG1” & “NG2”) and downloaded 500 headers from both. I selected NG1 again and I see only threads that are collapsed.
2. From the menu, I choose: View->Threads->Unread.

RESULT: all threads expand. That’s not an expected behaviour - all I’ve requested it to do is show only threads that are unread. It’s a undesirable behaviour, demonstrated in instances such as this particular test case where, due to many replies in the first thread and due to my screen’s limited height, only two different subjects (threads) are visible and as a result, I either have to manually collapse the thread(s) or scroll downwards many times to see any more subjects.

3. From the menu, I choose: View->Threads->Collapse All Threads

RESULT: all threads collapse.

4. I switch to NG2. I see only threads that are collapsed.
5. I repeat Step#2, with the same result.
6. I repeat Step#3, with the same result.
7. I switch to NG1. Despite having left it in a collapsed state, I now only see threads that are expanded.
8. I switch to NG2. Despite having left it in a collapsed state, I now only see threads that are expanded.
9. (Further test) I repeat #3 then close Thunderbird. Upon restarting Thunderbird, It starts up in the newsgroup that I’d last been in, but despite me having left it in a collapsed state, I now only see threads that are expanded.

The root of the problem seems to be that when Threads->Unread is manually enabled, a variable is set to a state that triggers threads to be expanded. Unless or until the user switches to ‘Threads->All’, that setting seems to remains unchanged, completely independent from whatever the ‘collapse’ and ‘expand’ commands do. So when the folder is exited and later re-entered, the variable’s value is checked and its ‘expand’ status commands all threads to always be expanded."

Comment 11

[marvin.heilemann]

Any activity on this? With the latest version of Thunderbird on lates macOS I still have this. I have grouped my folders and sorted by Date and enabled tree/thread view. Collapsing a thread, going to another folder or inbox and returning expands all threads again. I would like to have them collapsed by default. Can this be added as a global option please?

Comment 12

[Hartmut Welpmann [:welpy-cw]]

This should be fixed now by bug 1807063.