Default or custom thread pane / message list column order is reset to bogus order (icon cols first) after every restart of TB (esp. involving icon colums)
Categories
(Thunderbird :: Folder and Message Lists, defect, P1)
Tracking
(Not tracked)
People
(Reporter: Arkane, Unassigned)
References
()
Details
(Keywords: regression)
After updating to Version 74.0b1 the column order changed to "Thread/Starred/Attachements/Read/Junk Status/Correspondents/Date". After changing it back to my prefered order or after using "Restore Column Order" it resets back to "Thread/Starred/..." after closing and restarting Thunderbird.
74.0b2 didn't change this behaviour, 73.0b didn't show this error after reinstalling it. I used fresh profiles and disabled my addons.
After changing the order to my preference and restarting 74.0b in Safe Mode my prefered order persists, disabling Safe Mode reverts the order back to ""Thread/Starred/...".
Updated•5 years ago
|
Comment 1•5 years ago
|
||
I lately observed the same issue for the French Thunderbird 75.0b1 version. Don't remember whether the issue already existed in TB 74.0b1 or 74.0b2.
Running macOS 10.14.6.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Looks like a duplicate of bug 1612055.
Reporter | ||
Comment 3•5 years ago
|
||
(In reply to Christian Riechers from comment #2)
Looks like a duplicate of bug 1612055.
I think not: bug 1612055 describes the behavior of version 73 of changing the order after updating to that version. But this change is not permanent, if you are not visually impaired you can change it back to any order you like.
But with version 74 (this bug) the change is made permanent.
Comment 4•5 years ago
|
||
I'm experiencing this same issue on 77.
The issue presents itself only if icon columns (attachments, read, junk, etc.) are moved from their original location.
If those type of columns are moved, then the entire message list column ordering resets on restart.
If the reordered are only the text columns (subject, date, correspondent), and are ordered around each other, without affecting the icon columns, the new order is properly maintained on restart.
To summarize with some examples:
- Moving Date or Correspondent before Subject, the order REMAINS.
- Moving the Junk column, the order RESETS.
- Moving the Date column in between Junk and Read columns, the order RESETS.
Comment 5•4 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is --
(Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to --
(default, untriaged.)
Comment 6•4 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is --
(Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to --
(default, untriaged.)
Comment 7•4 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is --
(Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to --
(default, untriaged.)
Comment 8•4 years ago
|
||
The severity of these bugs was changed, mistakenly, from normal
to S3
.
Because these bugs have a priority of --
, indicating that they have not been previously triaged, these bugs should be changed to Severity of --
.
Comment 9•4 years ago
|
||
As I pointed out in related bug 1612055, comment 5, imo this is a pretty serious UX failure which messes up TB's thread pane UI, very error-prone for users of read-column where slight misclick will mark their messages spam.
Confirming as a bug in its own right. If we could fix this bug 1622255, at least that would be a bandaid workaround for bug 1612055.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Bug 1612055 has now landed on daily. Can you recheck if this problem is still there?
Comment 12•4 years ago
|
||
Thanks! ->WFM
Updated•4 years ago
|
Comment 14•4 years ago
|
||
Yes, this is another symptom of bug 1612055, and was explicitly fixed there according to Bug 1612055 Comment 33.
Thanks to Thomas Faßnacht for reporting this, testing again and reporting back! Much appreciated.
Thomas D. :-)
Description
•