Open Bug 1411905 Opened 7 years ago Updated 1 year ago

message threads are all expanded when I switch folders

Categories

(Thunderbird :: Mail Window Front End, defect)

52 Branch
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: registrations, Unassigned)

References

Details

(Whiteboard: [dupme])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce: I use message threading in my Inbox. Some threads are open; some are closed. Click on another folder. Click back into the Inbox. Actual results: Since I upgraded to v52.4.0, all threads have been opened. Expected results: Before upgrading, the threads would have been open and closed when returning to the Inbox as they were when I was originally in the Inbox.
And that worked better in TB 52.3? There weren't any changes to threading between 52.3 and 52.4. I've done this in TB 45.8: - Go to a folder with only one thread in it. - Collapsed the tread. - Go to another folder and return to original folder. - Collapsed thread is open again. In bug 1369434 someone is complaining about the opposite, that threads are closed. Magnus, how is this meant to work?
Flags: needinfo?(mkmelin+mozilla)
Ideally I suppose the threads should keep the state they had. If you're asking what the logic in the code is, I don't know. I don't recall ever fiddling with this.
Flags: needinfo?(mkmelin+mozilla)
Alta88, you know much about views, can you please state the desired behaviour here.
(In reply to Jorg K (GMT+2) from comment #1) > And that worked better in TB 52.3? There weren't any changes to threading > between 52.3 and 52.4. > > I've done this in TB 45.8: > - Go to a folder with only one thread in it. > - Collapsed the tread. > - Go to another folder and return to original folder. > - Collapsed thread is open again. > > In bug 1369434 someone is complaining about the opposite, that threads are > closed. > > Magnus, how is this meant to work? I can't be certain that it was 52.3 I upgraded from, though it is probable. I have only noticed this behaviour since I upgraded to 52.4. Previously the threads kept the state they had. Have found a keyboard shortcut to close them all while I was using Bugzilla, which helps.
This has been a nuisance for years already, either all threads or very many threads are expanded. A function to collapse all wouldn't help as I want a few current ones to stay expanded. Basically, the previous collapsed/expanded status should be re-established.
Whiteboard: [dupme]
Version: unspecified → 52 Branch

Tom, Anita,

Does it also happen if you create a new profile? (don't delete the old one)
https://support.mozilla.org/en-US/kb/using-multiple-profiles

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

Flags: needinfo?(towo)
Flags: needinfo?(registrations)

Hi Wayne,

I created a new profile and the folders stay open/closed and in that profile the message threads behave as I would expect.

Kind regards,

Anita

Flags: needinfo?(registrations)

Quite a while ago there was work done to fix major problems in grouped by sort view, and part of this included persisting thread collapsed/expanded state across folder changes and restarts. There is no individual thread state persisted, it is either all or none per folder, and this state is set (only) by View->Threads and Expand All/Collapse all.

This is wfm unless demonstrable on current trunk.

Note that if expand all is set, and every thread is individually collapsed, the persist state is still expand all.

Of course it would be great to persist the state of every thread in every folder. It could certainly be implemented.

Would a rough translation of that be that if I configured my new profile with my email accounts and use that one instead of the default one that I should be ok?

(In reply to Anita Davies from comment #9)

Would a rough translation of that be that if I configured my new profile with my email accounts and use that one instead of the default one that I should be ok?

No, you should be able to use the old profile and use the menu option to set desired collapsed/expanded state for that folder.

I'm getting weekly "needinfo" reminders so I'm responding. Haven't tried a second profile yet and honestly I don't feel like tampering with my application configuration so much unless there would be an idea why and how that could yield valuable information.

Flags: needinfo?(towo)
Severity: normal → S3
See Also: → 1807063
You need to log in before you can comment on or make changes to this bug.