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.

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?

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.

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?

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?

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

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.

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 ?

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.

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

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?

(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

I think Mark's expected behaviour seems reasonable.

Isn't that bug 710056 ?

(In reply to Ludovic Hirlimann [:Usul] from comment #13) > Isn't that bug 710056 ? depends if bug 710056 is truly a v10 regression

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.

(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.

xref Bug 813539