1622255 - 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)

Status: VERIFIED DUPLICATE of bug 1612055

(Thunderbird :: Folder and Message Lists, defect, P1)

Description

[Thomas Faßnacht]

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/...".

Comment 1

[Eckard Berberich]

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.

Comment 2

[Christian Riechers]

Looks like a duplicate of bug 1612055.

Comment 3

[Thomas Faßnacht]

(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

[Alessandro Castellani [:aleca]]

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

[Firefox Bug Husbandry Bot]

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

[Firefox Bug Husbandry Bot]

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

[Firefox Bug Husbandry Bot]

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

[Firefox Bug Husbandry Bot]

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

[Thomas D. (:thomas8)]

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.

Comment 10

[Magnus Melin [:mkmelin]]

Bug 1612055 has now landed on daily. Can you recheck if this problem is still there?

Comment 11

[Thomas Faßnacht]

In the Daily Build the problem is gone

Comment 12

[Magnus Melin [:mkmelin]]

Thanks! ->WFM

Comment 14

[Thomas D. (:thomas8)]

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. :-)