Sort by unthreaded is not applied to all folders and its children (only some)
Categories
(Thunderbird :: Folder and Message Lists, defect)
Tracking
(Not tracked)
People
(Reporter: randomuser123x, Unassigned)
References
(Blocks 1 open bug, )
Details
Steps to reproduce:
I have 10 Google IMAP accounts. With the latest Thunderbird update (102.0) I have noticed that message lists of some of my accounts' folders are not sorted appropriately (unthreaded) as they used to be before the update.
- View/Sort by/Unthreaded
- Apply columns to.../folder and its children/account-name
Actual results:
"Sort by unthreaded" setting is not being applied to some folders.
Expected results:
"Sort by unthreaded" setting should be applied to all folders.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
The default was changed to threaded in bug 1764842.
It was only meant to effect newly created folders though. Did you recreate your profile for 102, or is this from an upgrade from 91 to 102?
If it is the latter, I suspect it may be that since the ordering was never changed from the default, the preference was never set for the existing folders, so they fall back to the new default.
Reporter | ||
Comment 2•3 years ago
|
||
It was an upgrade but I keep Thunderbird up to date with each release. It is the 102 update that cause it. I've noticed it immediately after the launch as my Unified Inbox was also switch to threaded. I did re-apply the unthreaded sort by to all my accounts but as I stated in the original post, it doesn't apply to some subfolders of some Google IMAP accounts even if I do it over and over again.
I experienced the same behaviour. I never used threaded view in Thunderbird. I upgraded from 91.11.0 x64 to 102.0 x64 through the "About Thunderbird" window.
The interesting thing is, my 2 Gmail accounts got set to threaded view, several accounts from other providers remained unchanged!
So there must be something that thinks the gmail accounts are newly added when upgrading the version.
Maybe it has something to do with the OAuth2 verification? Thats the only thing i can think of, thats different between Gmail and the other IMAP-Accounts.
Reporter | ||
Comment 4•3 years ago
|
||
I would like to add additional issue I've been experiencing which might be related to the bug. The two of my Google IMAP accounts that do not apply the unthreaded sort by are also irregularly excluded from Unified Folders (such as Inbox, Drafts, Sent, Archives, Junk and Trash) in random order. I've had to manually tick them in the properties of the Unified Folders a few times already.
Comment 5•3 years ago
|
||
@rnons Similar to bug 1777731, this might also be from bug 1573690 / bug 1483485 which may have caused the folder URIs to change and loose the corresponding folder setting?
Comment 6•3 years ago
|
||
I doubt it, bug 1483485 changes folder URI for the frontend, but the underlying folder (e.g Inbox and Inbox.msf) should be intact. There are other reports about .msf got corrupted, like bug 1773822.
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Maybe those child folders had their .msf removed... (Bug 1773822)
Reporter | ||
Comment 8•3 years ago
|
||
I can confirm that the issue still occurs with version 102.0.2 of Thunderbird.
I don't think I'm missing any .msf files. I have 10 Google IMAP accounts (so lots of .msf). I've been trying to apply threaded/unthreaded-sort-by to a few of my accounts. Unfortunately, in all cases the problem is still there. I can select it manually for each folder but doing it manually for 100+ folders/sub-folders is a nightmare.
Comment 10•3 years ago
|
||
Not sure how / why this escaped regression Q/A. Unless intended behaviour which would indicate poor design / implementation as changing this w/o user consent (ie. a configuration setting which is observed by the code, the relevant code apparently seems to be dead if I understand https://hg.mozilla.org/mozilla-central/rev/042de8e1b27c95f129099cf22d3456af1e547e60 correctly) under the hood is a no-go.
I'm sure that the author of the previous comment is not the only struggling with this issue.
Please prioritise if possible and fix ASAP. It would be a shame if an otherwise excellent software product suffers from decreasing user acceptance due to such an issue.
Comment 11•3 years ago
|
||
Alex, is this intended behavior?
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
It's intended that it doesn't apply to old folders yes. The "some" part probably happened due to bug 1773822.
Bug 574986 to make it easier to change for many folders.
Comment 14•2 years ago
|
||
I can confirm, after upgrading to v102, all folders have been switched to threads, which is unwanted behavior. There is no easy way to disabled it on global level or at least on account level and it needs to be disabled for each folder.
Comment 15•2 years ago
|
||
(In reply to Daniel from comment #14)
I can confirm, after upgrading to v102, all folders have been switched to threads, which is unwanted behavior. There is no easy way to disabled it on global level or at least on account level and it needs to be disabled for each folder.
Please, don't comment on closed bugs and reach out in the support forum for these type of issues.
Nonetheless, you can make the folder unthreaded and then click on the "column display" icon (the last column of the message thread pane) and select Apply current view to...
> Folder and its children...
to update everything at once.
Comment 16•2 years ago
|
||
(In reply to Alessandro Castellani [:aleca] from comment #15)
(In reply to Daniel from comment #14)
I can confirm, after upgrading to v102, all folders have been switched to threads, which is unwanted behavior. There is no easy way to disabled it on global level or at least on account level and it needs to be disabled for each folder.
Please, don't comment on closed bugs and reach out in the support forum for these type of issues.
Nonetheless, you can make the folder unthreaded and then click on the "column display" icon (the last column of the message thread pane) and selectApply current view to...
>Folder and its children...
to update everything at once.
This workaround doesn't do anything either, bug is still present in 102.4.0.
Description
•