563254 - Column list order perceived to be forgotten

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Mark Banner (:standard8)]

Build: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.5pre) Gecko/20100502 Lightning/1.0b2pre Lanikai/3.1pre

Approximate STR:

1) Have a folder that you haven't customised the columns or changed the sort order on.
2) Select Folder
3) Restart Thunderbird

=> Folder is selected, note column order is not expected order (thread, star, read, from, junk, date, attachment, subject)

4) Select another folder that has not been customised

=> Column order stays the same

5) Select a folder that has been customised

=> Column order is reset to standard (thread, star, attachment, subject, read/from/junk/date)


Notes: I've seen this occur with Local Folders and newsgroups.

Setting the blocking request as it keeps making me think that I've lost the column order on a folder every time I start up on one of them.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Andrew, current speculation is that this might be related to one of your recent changes.  We don't yet have a feel for how many people this is likely to effect how often.  Can you investigate a bit so that we can have more info before we make a blocking decision here?

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

I didn't change anything related to this logic recently.  The 'apply to other folders logic' just blindly propagates state but does not change the underlying FolderDisplayWidget logic related to initial loading/display.

Since the logic is covered by relatively thorough mozmill tests, I think perhaps having QA try and farm out some investigatory probing might make the most sense.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

That sounds reasonable.  Ludo, could you find someone to take a look at this with an eye towards understanding how many people it effects, whether it's a regression, and if so, when it crept in?

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Since Ludo is out of the office for a bit, I've CCed Wayne and Gary.  Wayne, Gary, would either of you guys be able to find someone to look into this a bit more, as per comment 3?

Comment 5

[Wayne Mery (:wsmwk)]

Mike or Dossy, possible for you to have a look at...

> with an eye towards understanding how many people it effects, whether it's a
> regression, and if so, when it crept in?

+ Joe perhaps knows some Mac people from mz

Comment 6

[:Dossy Shiobara]

I haven't tried the STR, but I've noticed this in at least TB 3.0.x - not sure when I first noticed it, but whenever it happens (column order and/or added/removed columns reset) it's an inconvenience.

Comment 7

[Michael A. Pasek]

I don't have a copy of Lanikai (yet), but following the STR, this doesn't occur for me with 3.1a1pre/OS10.5.8.  However, that is WITHOUT Lightning installed; has the reporter tried this with Lightning disabled and/or in SafeMode ?

Comment 8

[Mark Banner (:standard8)]

I've just taken a more in-depth look at this. Here's a slightly more detailed STR:

1) Start with three folders all uncustomised.
2) Change the order of columns in two of the folders so that all three have different orders set.
3) Select the first customised folder, then select the uncustomised folder

Expected: Columns in the default order
Actual: The columns are in the order of the customised folder.

4) Select the second customised folder, then select the uncustomised folder

Expected: Columns either in the default order, or the order of the first customised folder.
Actual: The columns are in the order of the second customised folder.


I dug back to TB 3 and its behaviour is the same as the latest 3.1 builds. It seems that Thunderbird 2 applied the same column order across all folders (except maybe sent). So I don't think that this is a regression, strictly speaking.

I think this bug is more up to Bryan now to confirm what he'd like us to be doing in this situation.

Comment 9

[Bryan Clark (DevTools PM) [:clarkbw]]

I shouldn't be the assignee for these bugs.  Filter against clarkbfilter to delete all these from your emails.

Comment 10

[WADA:World Anti-bad-Duping Agency]

Bug 710056 (and dups of it, bug 717107, bug 720674, bug 723007) and bug 740740 are recently opened for loss of column selection/order change, and it sounds to happen frequently when auto-restart of Tb by software update.

Because column selection/column order is saved in .msf file like next, both are usually affected at same time, although only "loss of column order change" is observed, if "default column setting" is used and only column order only is changed, and if column selection data in .msf file is somehow lost or is not saved to .msf.
> @$${16{@
> <(BA
>     ={"threadCol":{"visible":false,"ordinal":"1"},"flaggedCol":{"visible":fals\
> e,"ordinal":"3"},"attachmentCol":{"visible":false,"ordinal":"5"},"subjectCol":\
> {"visible":true,"ordinal":"7"},"unreadButtonColHeader":{"visible":false,"ordin\
> al":"9"},"senderCol":{"visible":false,"ordinal":"11"},"recipientCol":{"visible\
> ":true,"ordinal":"21"},"junkStatusCol":{"visible":false,"ordinal":"13"},"recei\
> vedCol":{"visible":false,"ordinal":"35"},"dateCol":{"visible":true,"ordinal":"\
> 15"},"statusCol":{"visible":false,"ordinal":"17"},"sizeCol":{"visible":false,"\
> ordinal":"19"},"tagsCol":{"visible":true,"ordinal":"25"},"accountCol":{"visibl\
> e":true,"ordinal":"27"},"priorityCol":{"visible":false,"ordinal":"29"},"unread\
> Col":{"visible":false,"ordinal":"31"},"totalCol":{"visible":false,"ordinal":"3\
> 3"},"locationCol":{"visible":true,"ordinal":"37"},"idCol":{"visible":true,"ord\
> inal":"23"}})>[1:^9F(^B6^BA)]
> @$$}16}@

"Column selection/order chage of opened folder" is not written to .msf file immediately. If opened folder, it's written by folder close(MsgDB) and/or by MsgDB close upon termination of Tb. This is also true when "Appliy columns to..."(new from Tb 10?) is executed.
So, if Tb's termination is abnormal and column selection/order change is not written to .msf, the change is lost when Tb is restarted.

Is this kind of "abnormal termination of Tb" involved in your cases?

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to Mark Banner (:standard8) from comment #8)
> I think this bug is more up to Bryan now to confirm what he'd like us to be
> doing in this situation.

throwwing over the fence to bwinton

Comment 12

[Blake Winton (:bwinton) (:☕️)]

I think Mark's expected behaviour seems reasonable.

Comment 13

[Ludovic Hirlimann [:Usul]]

Isn't that bug 710056 ?

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to Ludovic Hirlimann [:Usul] from comment #13)
> Isn't that bug 710056 ?

depends if bug 710056 is truly a v10 regression

Comment 15

[Wayne Mery (:wsmwk)]

preliminary reports from Walt are this is WFM. (I haven't tested myself)
Can anyone still reproduce?

If it is gone, lets dupe to bug 10056.

Comment 16

[WaltS48 [:walts48]]

(In reply to Wayne Mery (:wsmwk) from comment #15)
> preliminary reports from Walt are this is WFM. (I haven't tested myself)
> Can anyone still reproduce?
> 
> If it is gone, lets dupe to bug 10056.

Double checked today, and still don't see any changes to my column list order when testing TB 17.06, 22.0b1, and 24.0a1 64-bit versions on openSUSE 12.3.

The TB 24.0a1 tests were done with my production, and a newly created test profile.

Comment 17

[Wayne Mery (:wsmwk)]

xref Bug 813539

Comment 18

[Wayne Mery (:wsmwk)]

Mark do you still see this issue?

Comment 19

[Mark Banner (:standard8)]

Per previous comments happy for this to be closed as WFM.