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.
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).
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → Windows 2000
Summary: Collapsed threads become expanded when returning to folder/newsgroup using View->Messages->Unread → Threads always expanded when returning to folder/newsgroup with MailView (e.g. Unread)
Version: unspecified → Trunk
exact opposite of bug 319007 behavior
Status: NEW → RESOLVED
Last Resolved: 11 years ago
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → DUPLICATE
Duplicate of bug: 319007
didn't intend to dupe - sorry for bugspam.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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
Version: Trunk → 1.5
(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...
(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.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:126.96.36.199) 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.
Please could the keyword ux-control be added to this bug.
You need to log in before you can comment on or make changes to this bug.