Closed Bug 710056 Opened 13 years ago Closed 12 years ago

Earlybird doesn't remember columns change in the message list after restart (only after restart of Tb which is automatically initiated when an update is applied by Help/About/Apply Update)

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Version:
10 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(thunderbird13-, thunderbird14-, thunderbird15-, thunderbird16+ fixed, thunderbird17+ fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 18.0
Tracking Flags:
Tracking Status
thunderbird13 - ---
thunderbird14 - ---
thunderbird15 - ---
thunderbird16 + fixed
thunderbird17 + fixed

People

(Reporter: mayhemer, Assigned: rkent)

References

(
URL
)

Details

(Keywords: qawanted, regression, Whiteboard: [gs][addon: test pilot?][STRs in comment 142]duptome)

Attachments

(3 files, 1 obsolete file)

log (as per comment 28)
13.91 KB, text/plain
Details
Add db to cache in SetSummaryValid
1.07 KB, patch
rkent
: review+
Bienvenu
: superreview+
standard8
: approval-comm-aurora+
standard8
: approval-comm-beta+
Details | Diff | Splinter Review
Checked in test
7.55 KB, patch
rkent
: review+
Details | Diff | Splinter Review 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111212 Thunderbird/10.0a2

STR:
- change the columns to display in Inbox (see bellow for details)
- optionally, sync them between other folders
- restart
-> folders are back as before

Details:
I want to have the following columns (ordered):
Thread, Attachment, From, Subject, Read, Starred, Date, Junk Status

I always get back the following:
Thread, Attachment, From, Subject, Recipient, Size, Starred, Date, Junk Status

(Read is altered with Recipient + Size)

The profile is very old, could that be some artifact breaking this?

It started to happen (or, I started to notice) some week ago after the columns broke (was set to "I always get back the following" list after restart).


I can try to bisect the changeset if this is not known.
Keywords: qawanted
Keywords: regression
I can't reproduce this with current nightly (version 12)

(In reply to Honza Bambas (:mayhemer) from comment #0)
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111212
> Thunderbird/10.0a2
> ...
> The profile is very old, could that be some artifact breaking this?

perhaps. but I have 5 year old profile and no problems

> It started to happen (or, I started to notice) some week ago after the
> columns broke (was set to "I always get back the following" list after
> restart).

I don't understand what this means.

> I can try to bisect the changeset if this is not known.

Are you perhaps seeing 
Bug 402135 - thread pane column sort order changes not saved once folder renamed
or 
Bug 550286 - Columns to display is lost if rebuild index is used on an IMAP folder 

Otherwise, I don't see any bugs with recent activity [1], so getting the range would be helpful.

[1] https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring&list_id=1935590&short_desc=column&field0-0-0=short_desc&type0-0-1=substring&field0-0-1=keywords&type1-0-1=allwordssubstr&resolution=---&classification=Client%20Software&classification=Components&chfieldto=Now&query_format=advanced&chfieldfrom=2011-10-01&short_desc_type=allwordssubstr&type0-0-0=anywordssubstr&component=Folder%20and%20Message%20Lists&field1-0-0=short_desc&product=MailNews%20Core&product=Thunderbird&field1-0-1=short_desc
Keywords: regressionwindow-wanted
(In reply to Wayne Mery (:wsmwk) from comment #1)
> > It started to happen (or, I started to notice) some week ago after the
> > columns broke (was set to "I always get back the following" list after
> > restart).
> 
> I don't understand what this means.

Yep, so, I wanted to say I first noticed this bug few weeks ago.  The symptom was that columns started to "reset" after restart to a state described as "I always get back the following" in comment 0.

> Are you perhaps seeing 
> Bug 402135 - thread pane column sort order changes not saved once folder
> renamed

I renamed a very very long time ago "Inbox" to "-" (seeing Inbox everywhere in the folder tree view driven be crazy).  Is that what is that bug about?

> or 
> Bug 550286 - Columns to display is lost if rebuild index is used on an IMAP
> folder 

I'm not using IMAP with any of my accounts.


I'll try to find the regression range somehow or simply fix the issue.
I just saw something with 20120102 build, not with restart and I wasn't specifically testing for this bug. And I don't normally have size column on inbox. 

But I just added it on home laptop as last column, and I am (seemingly suddenly) seeing size column removed from inbox when I switch to other folder and back to inbox. When switching back to inbox, the size column appears breifly, then disappears. 

I moved the size to not be last column, and now I cannot reproduce.
I've been seeing the same sort of thing happening in the Daily nightlys. It started about 1-1/2 to 2 weeks ago.

For about a week the Inbox columns would only reset to default maybe every other day or so when starting up a new nightly. For the past few days, it's happening a couple of times a day.

It's sporadic and I'm not able to reproduce it at will.

I ran Earlybird for two days on the same profile and didn't have any problem with it. I switched back to Daily yesterday and the columns reset on first run as well as after my pc was shutdown overnight and a cold restart this morning.

I downloaded todays Daily this morning and the same reset happened on first run. I shut down the pc at lunch, restarted after a couple of hours and the Inbox columns were reset again to default.

Changing the Size column from the last position hasn't made any difference.

I use zip builds and unpack into a new folder with each build change.

POP3 with one account.
When did tabs on top check in?
(In reply to Wayne Mery (:wsmwk) from comment #5)
> When did tabs on top check in?

Originally on 12-20-11 http://hg.mozilla.org/comm-central/rev/3f507b7d7ee6
There were also a couple of polish type checkins on 12-28-11.
I've switched back to Mozilla/5.0 (Windows NT 5.1; rv:11.0a1) Gecko/20111219 Thunderbird/11.0a1 and will see what happens.

The columns did not reset on first run with this build. I'll see what happens tonight and tomorrow.
trying to finger TOT was a random shot - I don't keep track of the UI related checkins. hopefully honza or someone can bisect.
(In reply to Wayne Mery (:wsmwk) from comment #8)
> trying to finger TOT was a random shot - I don't keep track of the UI
> related checkins. hopefully honza or someone can bisect.
That's okay. That seemed to me to be the logical place to start with the major UI change that took place.

Although the Earlybird build I ran has TOT as well, I didn't have any problems with it so hunting down a regression range is going to take some time for me at least.
Looks like you are hunting a different symptoms: I got columns reset only and only right after restart, immediately.

Right now I'm very busy, but I'll try to find time to bisect.

Thanks for all the effort to fix this!
FWIW, http://forums.mozillazine.org/viewtopic.php?f=31&t=2397119 claims a column problem caused by compactheader addon
Yeah, I saw that thread too. I'm not using that extension, perhaps Honza is.

Yesterday, I deleted the json and msf files to let Thunderbird generate new ones and installed todays Daily. So far, the columns haven't reset...yet. I don't know if those files would have anything to do with the column order or not.
(In reply to Bozz from comment #12)
> Yeah, I saw that thread too. I'm not using that extension, perhaps Honza is.
> 
> Yesterday, I deleted the json and msf files to let Thunderbird generate new
> ones and installed todays Daily. So far, the columns haven't reset...yet. I
> don't know if those files would have anything to do with the column order or
> not.

No add-ons.  Just Test Pilot for TB.

Lose of columns happens just sometimes, not always after restart.  Mainly not when I'm trying to reproduce ;)
Is it just some folders? What happens if when you hit this state, you switch to a "good" folder and then back to the one that's "broken"?
(In reply to Honza Bambas (:mayhemer) from comment #0)
> STR:
> - change the columns to display in Inbox (see bellow for details)
> - optionally, sync them between other folders
> - restart
> -> folders are back as before
> Details:
> I want to have the following columns (ordered):
> Thread, Attachment, From, Subject, Read, Starred, Date, Junk Status
> I always get back the following:
> Thread, Attachment, From, Subject, Recipient, Size, Starred, Date, Junk,  
> Status 
> (Read is altered with Recipient + Size)

Tb trunk(2012/01/03 build) behavior on column of thread pane.
  Non special folder(not Trash, Junk, Archive, Sent, Drafts, Templates) 
    create new folder : Same column set in same order as Inbox of the account
    after delete .msf : Same column set in same order as Inbox of the account
  Inbox, after delete Inbox.msf : (in next order)
    Thread, Starred, Attachments, (Subjects), Read, From, Junk Status, Date
    (Subject is always shown, and it can't be hidden)
  IIRC, Sent and Drafts has different internal default from Inbox.
After delete of Inbox.msf, Tb 9.0.1 also showed following columns in next order. 
> Thread, Starred, Attachments, (Subject), Read, From, Junk Status, Date

Order of column is different from one I saw, but shown columns are absolutely same as one after delete of Inbox.msf. It looks changed back to "internal default of Inbox".

Current column set/order of a folder is saved in .msf, and it can be known by data like next in .msf file.
(Just after delete of Inbox.msf and restart)
> <(97=a7df)(98=4f0d1009)(99=)(9E=1326258051)(9B=12)(9C
>     ={"threadCol":{"visible":true},"attachmentCol":{"visible":true},"flaggedCo\
> l":{"visible":true},"subjectCol":{"visible":true},"unreadButtonColHeader":{"vi\
> sible":true},"senderCol":{"visible":true},"recipientCol":{"visible":false},"ju\
> nkStatusCol":{"visible":true},"dateCol":{"visible":true},"locationCol":{"visib\
> le":false}})>
(After some modifications, addion/deletion of mails, Compact, Repair Folder, ...)
> <(80=1)(81=4)(82=AAA)(83=0)(84=4f0d0cd6)(85=)(86=1326255321)(87=12)
>   (88
>     ={"threadCol":{"visible":true,"ordinal":"1"},"flaggedCol":{"visible":true,\
> "ordinal":"3"},"attachmentCol":{"visible":true,"ordinal":"5"},"subjectCol":{"v\
> isible":true,"ordinal":"7"},"unreadButtonColHeader":{"visible":true,"ordinal":\
> "9"},"senderCol":{"visible":true,"ordinal":"11"},"recipientCol":{"visible":fal\
> se,"ordinal":"17"},"junkStatusCol":{"visible":true,"ordinal":"19"},"receivedCo\
> l":{"visible":false,"ordinal":"35"},"dateCol":{"visible":true,"ordinal":"21"},\
> "statusCol":{"visible":true,"ordinal":"13"},"sizeCol":{"visible":false,"ordina\
> l":"23"},"tagsCol":{"visible":false,"ordinal":"25"},"accountCol":{"visible":fa\
> lse,"ordinal":"27"},"priorityCol":{"visible":false,"ordinal":"29"},"unreadCol"\
> :{"visible":false,"ordinal":"31"},"totalCol":{"visible":false,"ordinal":"33"},\
> "locationCol":{"visible":false,"ordinal":"37"},"idCol":{"visible":true,"ordina\
> l":"15"}})>

What is saved in Inbox.msf after column selection change of Inbox(Read => Recipient + Size) and termination of Tb?
When column set is changed back to internal default of Inbox(perhaps) after restart of Tb, is there any error in Error Console? (e.g. error relevant to folderTree.json, exception relevant to thread pane processing)
(In reply to Honza Bambas (:mayhemer) from comment #2)
> The symptom was that columns started to "reset" after restart (snip)
(In reply to Honza Bambas (:mayhemer) from comment #10)
> I got columns reset only and only right after restart, immediately.

You are not alone.
Bug 717107 is for same symptom when "Upgraded to newest beta 10" for phenomenon of "added From is lost after restart of Tb by upgrade of Tb".
(In reply to WADA from comment #16)
> You are not alone.
> Bug 717107 is for same symptom when "Upgraded to newest beta 10" for
> phenomenon of "added From is lost after restart of Tb by upgrade of Tb".

Yes, this happens only when an update is applied (Help/About/Apply Update).  Close and start again doesn't alone reproduce this bug.(In reply to Mark Banner 

(:standard8) from comment #14)
> Is it just some folders? 

Looks like only Inbox is doing this.

> What happens if when you hit this state, you switch
> to a "good" folder and then back to the one that's "broken"?

Returning from a good folder (any other then Inbox) to Inbox doesn't change anything, columns are still broken.
(In reply to Honza Bambas (:mayhemer) from comment #17)
> Yes, this happens only when an update is applied (Help/About/Apply Update). 
> Close and start again doesn't alone reproduce this bug.

Reflecting it to bug summary, in order to avoid misleading.

As you say, I can't see phenomenon of "loss of folder column selection change after restart of Tb" by ordinal/normal termination/restart of Tb.
And, today, I was informed "update for Tb 9.0.1 is available"(update code looks already dwnloaded) while I'm using Tb 8.0 ja today, so I changed folder column selection of Inbox of a POP3 account and requested install/restart of Tb via Help/About/Apply Update. However, I couldn't see phenomenon of "loss of folder column selection change, at folder where the folder selection change was made just before restart, just after restart of Tb forced by Help/About/Apply Update".

After any ordinal termination of Tb, I could see latest folder column selection information in <foldernam>.msf file for which folder column selection was made just before termination of Tb, for any of real/virtual folder of folder view=All(or All Folders) and Unified Folder of folder view=Unified Folders and real folder of folder view=Unified Folders(folder of account name under Inbox, Set, Drafts, ...).
This is true with both Tb 9.0.1 and Tb trunk 12.0a1pre 2012/01/15 build.

Upgrade of 10.0a2 builds resets folder column selection to internal default set of folder column setting?
   
Do you see your problem on Sent/Drafts too? (internal default is different from one for Inbox and ordinal folder. From is chosen for Inbox family, but Reciipient is chosen for Sent/Drafts in default set of folder column setting.)  

Are you talking about phenomenon with/on which?
- with Folder view=All, Unified Folders, or other than All/Unified Folders
- if with Folder view=Unified Folders, on which folder
  - on Unified Folder (Inbox, Drafts, Sent, ...)
  - on actual folder (folder of account name under Inbox, Drafts, Sent, ...)
- if with Folder view=All(or All Folders)
  - folder column selection change at Inbox of accountX before restart,
    on column selection at same Inbox of accountX after restart
  - folder column selection change at Inbox of accountX before restart,
    on column selection at Inbox of different accountY after restart
Summary: Earlybird doesn't remember columns change in the message list after restart → Earlybird doesn't remember columns change in the message list after restart (only after restart of Tb which is automatically initiated when an update is applied by Help/About/Apply Update)
The bug is here after upgrade to TB 10.1.
(In reply to Constantin Stefanov from comment #22)
> The bug is here after upgrade to TB 10.1.
TB 10.0, sorry.
I need an advice how to simulate an update.  I can have a debug build in a minute, but I have no idea how to force it to restart because of an update.  Then I can spend time on bisecting.
(In reply to Honza Bambas (:mayhemer) from comment #0)
> STR:
>(snip)
> - optionally, sync them between other folders

Does it mean you did "Apply columns to"/"Foder and its children(or Folder)", select account or folder, reply OK at dialog, before restart?

- restart
-> folders are back as before

(Case-A)
When "Apply colums to" is executed, column selection status is immediately applied to other mail folder(s) and is immediately written in .msf file, but it looks for non-opend mail folder only.
If a mail folder is selected and opened at other Tb Window, column selection of the folder is not changed(needless to say, it is not written to .msf upon Apply colums to, and it is not written to .msf upon MsgDB close because column selection is not changed yet.) 
So, if you see the folder after restart of Tb, it looks "column selection change is lost by resart".

Are you seeing this phenomenon.

(Case-B)
If column selection is changed at a folder(call FolderX) and "Apply columns to" is executed at the folder(FolderX), the new column selection of FolderX is not writen in FolderX.msf yet because FolderX is still opened. The new column selection of FolderX is physically written in FolderX.msf file after close of FolderX.
So, if FolderX.msf is not physically updated by termination of Tb, it looks "column selection change is lost by restart" too.

Are you seeing this phenomenon.

(Case-C)
As seen in bug 712371 comment #31, if FOLDER_SUMMARY_OUT_OF_DATE condition is found during restar of Tb, .msf file looks deleted to force FOLDER_SUMMARY_MISSING condition in next MsgDB open, and Rebuild-Index is invoked upon next MsgDB open because of FOLDER_SUMMARY_MISSING condition.
If opened MsgDB is not closed properly when forced termination by update, Rebuild-Index due to FOLDER_SUMMARY_OUT_OF_DATE may occur during following restart of Tb.
If .msf is deleted, Tb perhaps set following as column set of the folder.
  Inbox.msf            : Internal default for Inbox
                         (column set by "Reset columns to default" of Inbox)
  Non-sent type folder : Columns which is currently set for Inbox
  Sent.msf             : Internal default for Sent
                         (column set by "Reset columns to default" of Sent)
  Sent type folder     : Columns which is currently set for Sent
                         (Drafts, Templates, Outbox only?)

FOLDER_SUMMARY_OUT_OF_DATE condition and FOLDER_SUMMARY_MISSING condition can be detected by "error opening db 80550005" and "error opening db 80550006" of MSGDB:5 NSPR logging.
Can you get MSGDB:5 during forced restart of Tb after Tb update?
"Apply to all columns"/"to this one only" is not needed to reproduce.  If I remember correctly, I experienced this bug the first time before I even knew these options were available.

> Can you get MSGDB:5 during forced restart of Tb after Tb update?

I'll do that.
can someone please confirm the information at https://getsatisfaction.com/mozilla_messaging/topics/folder_columns_wont_stay_set_keep_reverting_to_some_non_default_configuration  which claims test pilot is at fault?

I've labeled ~10 topics, that I was able to easily find going back to dec 1 2011, with https://getsatisfaction.com/mozilla_messaging/tags/bug_710056 (one or two cite version 9)

FWIW, I'm seeing this and I don't do auto updates.
URL: https://getsatisfaction.com/mozilla_m...
tracking-thunderbird13: --- → ?
Keywords: qawanted
Whiteboard: [gs]
I got my last tip on this from https://getsatisfaction.com/mozilla_messaging/topics/column_order_keeps_resetting_in_thunderbird_9#reply_8085958

i haven't fully tested yet, but it seems that column changes don't stick after tb restart for the last active tab, if tp is enabled.

I only tested moving attachment column.
(In reply to Wayne Mery (:wsmwk) from comment #30)
> I got my last tip on this from
> https://getsatisfaction.com/mozilla_messaging/topics/
> column_order_keeps_resetting_in_thunderbird_9#reply_8085958
> 
> i haven't fully tested yet, but it seems that column changes don't stick
> after tb restart for the last active tab, if tp is enabled.
> 
> I only tested moving attachment column.
I am using Test Pilot 1.3.6 and my columns are saved, what version are you using Wayne?
I'm using TP v1.3.5

it seems to not be a universal problem - some users don't see it
(In reply to Wayne Mery (:wsmwk) from comment #32)
> I'm using TP v1.3.5
> 
> it seems to not be a universal problem - some users don't see it

try 1.3.6 wayne and if you don't see the problem then it's a test pilot problem with pre 1.3.6 versions right?
TP 3.1.6 helped me. but i don't trust my testing.
I've emailed the newer TP to the other 3 people to test.
Please just use the Thunderbird Test Pilot 1.3.7 that is now on AMO.
I will do the test after upgrade to TB 11 in several days (I need upgrade for another bug report) and will post the reasults.
IMO (in my testing) an update was not required to reproduce this.  YMMV
Update...I had created a new profile recently and did not install test-pilot. I have been removing it before first run so it wouldn't install. I download the full zip build and have not been using auto-update.

I had a column reset happen again this morning. It happened after toggling the From column ascending/decending, deleted a few messages then manually compacted the folder. Toggled the messagepane during that time as well.

After restarting Thunderbird, the columns had reset to default.

Latest build I'm using is Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120314 Thunderbird/14.0a1
(In reply to Wayne Mery (:wsmwk) from comment #36)
> Constantin, Honza, 
> what are your results with
> https://addons.mozilla.org/en-US/thunderbird/addon/test-pilot-for-
> thunderbird/?src=search ?
I did not fully understand what I have to do with Test Pilot. I did not have it before and the bug was here (I restarted after upgrade to TB 11 to upgrade Lightning and saw columns reverting). I installed Test Pilot, TB required restart, I restarted and the columns reverted to default state againg, so the bug is still here.

Should I do anything else?
Don't do anything with test pilot - it seems I was wrong about this being a default addon in current versions.

bozz, can you track down which exact nightly build started this for you?
Version: Trunk → 10
FTR, looks like 10-12 recent reports of this in getsatisfaction.  unfortunately, no useful recent feedback there so far.
another thread at http://forums.mozillazine.org/viewtopic.php?f=31&t=2430683

Different ppl are reporting different symptoms [1]. Unclear if there are multiple problems.

[1] symptoms vary :( depending on reporter:
- only INbox affected  vs.  any folder affected
- only column order  vs.  column order not affected
- addon involved   vs  not 
- started version 9, started version 10, etc
Wayne asked me to post here, I am on 10.0.2 but my profile is probably three or four years old and has been carried over though various versions, PCs and operating systems.

This bug moved recently when I shifted my main email setup to a newer PC (using mozbackup) and that's what's suddenly made me realise it wasn't me. IIRC it started (or rather I noticed it) about four months ago).

I run a very vanilla setup with seven accounts and the standard folder setup, no extra folders, the only add-on I have is a UK-English dictionary. I don't *think* I have changed the column order from standard.

If I remove Recipient and reinstate Sent, then close TB and re-start, Recipient will have returned and Sent disappeared but only on the active Inbox when I exited. This happens whether I use Unified or All.

I can confirm column order is NOT affected though.

Happy to do any tests to try and clarify what's happening but please bear with me if I disappear for a few hours or days as I have a business to run and I'm point person for childcare at the mo.

Oh, and although I was on 10.0.2 when I started this post I'm now on 11.0 - still the same.
(In reply to Wayne Mery (:wsmwk) from comment #41)
> Don't do anything with test pilot - it seems I was wrong about this being a
> default addon in current versions.
> 
> bozz, can you track down which exact nightly build started this for you?

Sorry, but the problem doesn't occur consistently enough be able to track down a regression range in any sort of timely matter. It could a long time to find the build so I wouldn't be able to help out with that.
(In reply to Wayne Mery (:wsmwk) from comment #36)
> Constantin, Honza, 
> what are your results with
> https://addons.mozilla.org/en-US/thunderbird/addon/test-pilot-for-
> thunderbird/?src=search ?

No change.
I'm not sure if this is the bug I originated or a separate one, but I still occasionally experience the same thing.  My particular problem is that in the Inbox, the folders list "Recipient" rather than "From".  The only change I make is that I prefer to add the "size" column to all my accounts. Here is my info in the event it may assist you. BTW, when the Inbox columns revert to Recipient instead of FROM, I have started changing the columns to "Default", then adding the "Size" column. It seems to keep it from happening quite as often.
Thanks,
Margaret
(maggiemod)
PS: I am using Windows Vista Home Premium, SP2 (32 bit)

  Application Basics
    Name: Thunderbird
    Version: 11.0
    User Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
    Profile Directory: Open Containing Folder

              (Local drive)
    Application Build ID: 20120312212756
    Enabled Plugins: about:plugins
    Build Configuration: about:buildconfig
    Crash Reports: about:crashes
    Memory Use: about:memory

  Mail and News Accounts
    account1:
      INCOMING: account1, , (none) Local Folders, plain, passwordCleartext

    account2:
      INCOMING: account2, , (pop3) pop.gmail.com:995, SSL, passwordCleartext
      OUTGOING: smtp.gmail.com:587, alwaysSTARTTLS, passwordCleartext, true

    account3:
      INCOMING: account3, , (pop3) pop.gmail.com:995, SSL, passwordCleartext
      OUTGOING: smtp.gmail.com:587, alwaysSTARTTLS, passwordCleartext, true

    account4:
      INCOMING: account4, , (pop3) pop.gmail.com:995, SSL, passwordCleartext
      OUTGOING: smtp.gmail.com:587, alwaysSTARTTLS, passwordCleartext, true

    account5:
      INCOMING: account5, , (pop3) pop.gmail.com:995, SSL, passwordCleartext
      OUTGOING: smtp.gmail.com:587, alwaysSTARTTLS, passwordCleartext, true

    account6:
      INCOMING: account6, , (pop3) pop.gmail.com:995, SSL, passwordCleartext
      OUTGOING: smtp.gmail.com:587, alwaysSTARTTLS, passwordCleartext, true

    account7:
      INCOMING: account7, , (pop3) pop.gmail.com:995, SSL, passwordCleartext
      OUTGOING: smtp.gmail.com:587, alwaysSTARTTLS, passwordCleartext, true

    account8:
      INCOMING: account8, , (pop3) mail.comcast.net:995, SSL, passwordCleartext
      OUTGOING: smtp.comcast.net:587, alwaysSTARTTLS, passwordCleartext, true

    account10:
      INCOMING: account10, , (pop3) pop.gmail.com:995, SSL, passwordCleartext
      OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true

  Extensions
    AddressBookTab, 1.4.2, true, AddressBookTab@dischert.luc
    CompactHeader, 2.0.1, true, {58D4392A-842E-11DE-B51A-C7B855D89593}
    Duplicate Contact Manager, 0.8.2, true, {b4447f60-db9c-11da-a94d-0800200c9a66}
    Extra Folder Columns, 1.1.4, true, extra-cols@jminta_gmail.com
    Lightning, 1.3, true, {e2fda1a4-762b-4020-b5ad-a41df1933103}
    QuickFolders, 3.0.2, true, quickfolders@curious.be
    Test Pilot for Thunderbird, 1.3.7, true, tbtestpilot@labs.mozilla.com
    Attachment Sizes, 0.0.5, false, {90ceaf60-169c-40fb-b224-7204488f061d}
    Contacts Sidebar, 0.7.1, false, {4dce973c-25a5-4657-8e37-6c2a85c24a7e}
    Image Zoom, 0.4.6, false, {1A2D0EC4-75F5-4c91-89C4-3656F6E44B68}
    Quote Colors, 0.3, false, {B274D460-4DF9-454c-AC69-CA71398D7498}

  Modified Preferences

    Name: Value

      extensions.lastAppVersion: 11.0
      font.name.monospace.el: Consolas
      font.name.monospace.tr: Consolas
      font.name.monospace.x-baltic: Consolas
      font.name.monospace.x-central-euro: Consolas
      font.name.monospace.x-cyrillic: Consolas
      font.name.monospace.x-unicode: Consolas
      font.name.monospace.x-western: Consolas
      font.name.sans-serif.el: Calibri
      font.name.sans-serif.tr: Calibri
      font.name.sans-serif.x-baltic: Calibri
      font.name.sans-serif.x-central-euro: Calibri
      font.name.sans-serif.x-cyrillic: Calibri
      font.name.sans-serif.x-unicode: Calibri
      font.name.sans-serif.x-western: Calibri
      font.name.serif.el: Cambria
      font.name.serif.tr: Cambria
      font.name.serif.x-baltic: Cambria
      font.name.serif.x-central-euro: Cambria
      font.name.serif.x-cyrillic: Cambria
      font.name.serif.x-unicode: Cambria
      font.name.serif.x-western: Cambria
      font.size.fixed.el: 14
      font.size.fixed.tr: 14
      font.size.fixed.x-baltic: 14
      font.size.fixed.x-central-euro: 14
      font.size.fixed.x-cyrillic: 14
      font.size.fixed.x-unicode: 14
      font.size.fixed.x-western: 14
      font.size.variable.el: 17
      font.size.variable.tr: 17
      font.size.variable.x-baltic: 17
      font.size.variable.x-central-euro: 17
      font.size.variable.x-cyrillic: 17
      font.size.variable.x-unicode: 17
      font.size.variable.x-western: 20
      gfx.blacklist.direct2d: 3
      gfx.blacklist.layers.direct3d10: 3
      gfx.blacklist.layers.direct3d10-1: 3
      gfx.blacklist.layers.direct3d9: 3
      gfx.blacklist.layers.opengl: 3
      gfx.blacklist.suggested-driver-version: 10.6
      gfx.blacklist.webgl.angle: 3
      gfx.blacklist.webgl.msaa: 3
      gfx.blacklist.webgl.opengl: 3
      mail.openMessageBehavior.version: 1
      mail.winsearch.firstRunDone: true
      network.cookie.prefsMigrated: true
      places.database.lastMaintenance: 1331839661
      places.history.expiration.transient_current_max_pages: 73744
      places.history.expiration.transient_optimal_database_size: 117989866
      security.disable_button.openCertManager: false
      security.disable_button.openDeviceManager: false
      security.OCSP.disable_button.managecrl: false

  Graphics

    Adapter Description: ATI Radeon 3100 Graphics
    Vendor ID: 1002
    Device ID: 9613
    Adapter RAM: Unknown
    Adapter Drivers: atidxx32 atidxx64 atiumdag atiumdva atiumd64 atiumd6a atitmm64
    Driver Version: 8.479.0.0
    Driver Date: 4-22-2008
    Direct2D Enabled: Blocked for your graphics driver version. Try updating your graphics driver to version 10.6 or newer.
    DirectWrite Enabled: false (7.0.6002.18582)
    ClearType Parameters: ClearType parameters not found
    WebGL Renderer: Blocked for your graphics driver version. Try updating your graphics driver to version 10.6 or newer.
    GPU Accelerated Windows: 0/2. Blocked for your graphics driver version. Try updating your graphics driver to version 10.6 or newer.
****************
I recently experienced bug 730947 and I did a repair of the Inbox folder.  AFAIK this effectively deletes the msf file.  In comment 12 I read that it helps to fix this issue.  For me not.

I'm currently trying to get the log as mentioned in comment 28, is that still actual to help this bug?
(In reply to Honza Bambas (:mayhemer) from comment #48)
> I recently experienced bug 730947 and I did a repair of the Inbox folder. 
> AFAIK this effectively deletes the msf file.  In comment 12 I read that it
> helps to fix this issue.  For me not.

My comment 12 didn't resolve the issue for me either. Even creating a new profile as I mentioned in comment 39 hasn't resolved the problem, but the column reset does not happen as often now. I'm still unable to reproduce consistently.
(In reply to Margaret from comment #47)
> My particular problem is that in the Inbox, the folders list "Recipient" rather than "From".
> The only change I make is that I prefer to add the "size" column to all my accounts.
> Here is my info in the event it may assist you. 
> BTW, when the Inbox columns revert to Recipient instead of FROM,
> I have started changing the columns to "Default", then adding the "Size" column.
> It seems to keep it from happening quite as often.

As I wrote in comment #15, current column set/order is saved in .msf file after folder close and/or after termination of Tb.

What is saved in .msf file for column selection data, after your change of column selection and termination of Tb, before restart of Tb?
(View Inbox.msf file content by text editor)
It just happened to me again after updating from 11.0 to 11.0.1 (Win 7 Pro, 64-bit).

The Inbox.msf file (which I opened after restarting Thunderbird, but before closing it down again) contains two sections which appear to describe column settings, and they are not the same.  

Firstly, is it normal for there to be two such sections?

Secondly, the two sections are almost identical except for this part:

l":"5"},"senderCol":{"visible":true,"ordinal":"7"},"recipientCol":{"visible":f\
alse,"ordinal":"9"},"junkStatusCol":{"visible":false,"ordinal":"31"},"received\

l":"5"},"senderCol":{"visible":false,"ordinal":"7"},"recipientCol":{"visible":\
true,"ordinal":"9"},"junkStatusCol":{"visible":false,"ordinal":"31"},"received\

Notice that the visibility settings of the senderCol and receipientCol are reversed.

I have saved a copy of this version of Inbox.msf in case more information is required, although I'd rather not upload the entire file anywhere since it also contains many personal addresses and email content.
After changing the visibility back to my usual (Recipient hidden, From displayed), I quit Thunderbird, and reloaded it, and it had reverted again.

I did it again, quit Thunderbird, reloaded and this time it stuck!

After both steps I diff'd the Inbox.msf with my saved copy, and in neither case were the column descriptions quoted above updated.  So either it doesn't seem to be recording my preferences... or it is randomly selecting from one of the two sections in the file each time it starts up.
Hope it help.

FYI: I lost my Inbox file because of a system blue screen crash and I wasn't able to repair it.  So I'm redownloading emails from servers to a new fresh profile.

Also, my profile was quit crippled, so the problem could be more in a corrupted profile then TB it self.
Honza, any luck on bisect?

wada, what are you hoping the protocol log to reveal?
(In reply to Wayne Mery (:wsmwk) from comment #56)
> Honza, any luck on bisect?

I threw the profile away.  Now I have a new one, I don't have the issue with it.

> 
> wada, what are you hoping the protocol log to reveal?

Someone asked for it, so I provided it.
(In reply to Honza Bambas (:mayhemer) from comment #53)
> log (as per comment 28)

Which folder's which columns did you change before forced restart of Tb by upgrade or manual restart of Tb? 

Following is seen in log for Inbox of Local Folders. This indicates internal rebuild-index(repair folder) is invoked. 
> 2012-03-29 23:01:31.474000 UTC - 0[260f140]: nsMsgDatabase::Open(C:\Users\mayhemer\AppData\Roaming\Thunderbird\Profiles\78z36eb7.default\Mail\Local Folders\Inbox.msf, FALSE, d181ae0, TRUE)
> 2012-03-29 23:01:31.475000 UTC - 0[260f140]: error opening db 80550005
Was Inbox of Local Folders opened before the restart of Tb?
Was log data obtained by restart of Tb after blue screen & corrupted Inbox?  

"10 open DB's" is final status, but only three "closing database" is logged.
Is the log data saved after termination of Tb?
(In reply to WADA from comment #58)
> (In reply to Honza Bambas (:mayhemer) from comment #53)
> > log (as per comment 28)
> 
> Which folder's which columns did you change before forced restart of Tb by
> upgrade or manual restart of Tb? 

The global inbox (=Local Folders' Inbox file).

> 
> Following is seen in log for Inbox of Local Folders. This indicates internal
> rebuild-index(repair folder) is invoked. 
> > 2012-03-29 23:01:31.474000 UTC - 0[260f140]: nsMsgDatabase::Open(C:\Users\mayhemer\AppData\Roaming\Thunderbird\Profiles\78z36eb7.default\Mail\Local Folders\Inbox.msf, FALSE, d181ae0, TRUE)
> > 2012-03-29 23:01:31.475000 UTC - 0[260f140]: error opening db 80550005

I didn't run this manually.

> Was Inbox of Local Folders opened before the restart of Tb?

Yes, it was the current opened folder, I believe.

> Was log data obtained by restart of Tb after blue screen & corrupted Inbox?  

Yes, unfortunately :(  I didn't manager to do it sooner, sorry.

> 
> "10 open DB's" is final status, but only three "closing database" is logged.
> Is the log data saved after termination of Tb?

I think before.
(In reply to Honza Bambas (:mayhemer) from comment #59)
> > Was log data obtained by restart of Tb after blue screen & corrupted Inbox?  
> Yes, unfortunately :(  I didn't manager to do it sooner, sorry.

What is reason why you believe that such special case like after "blue screen & corrupted Inbox" is useful for analysis of your problem and improvement of quality of Tb?

> > "10 open DB's" is final status, but only three "closing database" is logged.
> > Is the log data saved after termination of Tb?
> I think before.

What is reason why you believe that such intermittent data is useful for analysis of your problem?
(In reply to WADA from comment #60)
> (In reply to Honza Bambas (:mayhemer) from comment #59)
> > > Was log data obtained by restart of Tb after blue screen & corrupted Inbox?  
> > Yes, unfortunately :(  I didn't manager to do it sooner, sorry.
> 
> What is reason why you believe that such special case like after "blue
> screen & corrupted Inbox" is useful for analysis of your problem and
> improvement of quality of Tb?

I was experiencing this bug before that crash/corruption.  The behavior according this issue remained the same after the crash/corruption.

I was throwing that profile away to be able to work again, so I made my self to produce the log, as somebody ask me a long time ago, at least with a crash/broken profile rather then not to produce it at all.

> 
> > > "10 open DB's" is final status, but only three "closing database" is logged.
> > > Is the log data saved after termination of Tb?
> > I think before.
> 
> What is reason why you believe that such intermittent data is useful for
> analysis of your problem?

I was asked to provide a log, so I did that.  I forgot to close TB simply before submitting the file, sorry!  This bug happens right after startup, so I think the log may contain the information that can help.

I don't know the code at all, so I cannot say.


At the moment, I have no setup to reproduce this bug.  (I suspect the profile be broken even before the blue-screen crash.)
Wondering if bug 550286 fixed this.
I encounter this problem quite regularly with my current profile.  Please let me know if there's any specific debugging data you would like me to capture.
As noted in comment #62, IMAP folder has bug 550286, and column selection data is always lost by "Repair Folder"(rebuild-index). Because rebuild-index of IMAP folder is similar to "delete .msf and delete offline-store file" currently, if out-dated-msf condition happens on IMAP folder and internal rebuild-index is invoked, loss of old .msf data will perhaps occur always.
Please rule out "IMAP folder case due to out-dated-msf" from this bug.
Phenomenon of "Column change is lost after restart of Tb" is easily be observed by next.
(1) Restart Tb, open a local mail folder(call FolderX).
    Columns of FolderX is read from FolderX.msf.
(2) Change columns of FolderX. Keep FolderX open.
(3) Kill Tb from Win's Task Manager(terminate thundirbird.exe process)
(4) Restart Tb. Open FolderX.
    Columns are same as (1), because column change at step (2) is not written to
    FolderX.msf due to kill.
    i.e. change at step (2) is lost after restart of Tb.

"Forced termination of Tb for restart of Tb by upgrade" may be similar to "Kill Tb at Task Manager".
Yes, the result is the same, but I doubt the cause is the same.

In my Inbox, I prefer to see a "From" column rather than a "Recipient" column.  I generally know who the messages in my Inbox have been sent to, i.e. myself.

When this problem occurs, I hide the "Recipient" column, and display the "From" column.  I then continue using Thunderbird for days, even weeks sometimes, closing it infrequently.  I generally hibernate my computer rather than shutting it down.  Meanwhile I would have changed to other folders frequently.  This, I assume, and my brief tests confirm, results in a write of the .msf.  I presume this is why you specifically instructed us NOT to change folders before killing thunderbird.exe.

When the next update comes out I will take before and after copies of the Inbox.msf.  Please let me know if there is any other data I should collect.  

Also, please do let me know if there is some way I can simulate an update (even if there is no update available) to help troubleshoot this issue.
(In reply to annihilannic from comment #66)
> Please let me know if there is any other data I should collect.  

"NSPR log with MSGDB:5,timestamp while forced termination only by upgrade" is preferable, in order to see MsgDB is closed or not by forced termination, although it's perhaps very hard on other than Win because log is perhaps overwritten by restart after forced termination.
If Win, it's possible with Debug View. See bug 402793 comment #6 for it.
  SET NSPR_LOG_MODULES=MSGDB:5  (no ,timestamp because DebugView adds it)
  SET NSPR_LOG_FILE=WinDebug
Another useful data is "Process Monitor" log of MS Win for Tb's file access to .msf files while forced termination.
http://technet.microsoft.com/en-us/sysinternals/bb545027
  http://technet.microsoft.com/en-us/sysinternals/bb896647 DebugView  
  http://technet.microsoft.com/en-us/sysinternals/bb896645 Process Monitor

> Also, please do let me know if there is some way I can simulate an update

A way to force software update.
(1) Install Tb 11.0(.0) or older Tb in different program directory, stop automatic update, start Tb 11.0(.0)
(2) Do software update to Tb 11.0.1 via Help menu.
I did this several times with Tb11.0.0 and Tb 11.0.1, but I couldn't observe problem of this bug.
Do you have a link to an 11.0.0 installer?  I had a dig around briefly but couldn't locate one.
(In reply to annihilannic from comment #68)
> Do you have a link to an 11.0.0 installer?

http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/
Oh, Tb 12.0(.0) looks released.
FYI.
I could see two text data for column setting in a .msf file which is shared by Tb 11.0.1 and Tb trunk(14.0a0).

(A) Column setting by Tb 11.0.1. Account/Location is shown.
> <(80=1)(89=36)(8A=4f94feb3)(83=4)(84=Column-Test)(81=0)(85=)(86=1335164526)
>   (87=12)(88
>     ={"threadCol":{"visible":true,"ordinal":"1"},"flaggedCol":{"visible":true,\
> "ordinal":"3"},"attachmentCol":{"visible":true,"ordinal":"5"},"subjectCol":{"v\
> isible":true,"ordinal":"7"},"unreadButtonColHeader":{"visible":true,"ordinal":\
> "11"},"senderCol":{"visible":true,"ordinal":"13"},"recipientCol":{"visible":fa\
> lse,"ordinal":"15"},"junkStatusCol":{"visible":true,"ordinal":"17"},"receivedC\
> ol":{"visible":false,"ordinal":"35"},"dateCol":{"visible":true,"ordinal":"19"}\
> ,"statusCol":{"visible":false,"ordinal":"21"},"sizeCol":{"visible":false,"ordi\
> nal":"23"},"tagsCol":{"visible":false,"ordinal":"25"},"accountCol":{"visible":\
> true,"ordinal":"27"},"priorityCol":{"visible":false,"ordinal":"29"},"unreadCol\
> ":{"visible":false,"ordinal":"31"},"totalCol":{"visible":false,"ordinal":"33"}\
> ,"locationCol":{"visible":true,"ordinal":"37"},"idCol":{"visible":true,"ordina\
> l":"9"}})>

(B) Column setting by Tb 14.01, after Account/Location is hidden.
> <(93
>     ={"threadCol":{"visible":true,"ordinal":"1"},"flaggedCol":{"visible":true,\
> "ordinal":"3"},"attachmentCol":{"visible":true,"ordinal":"5"},"subjectCol":{"v\
> isible":true,"ordinal":"7"},"unreadButtonColHeader":{"visible":true,"ordinal":\
> "11"},"senderCol":{"visible":true,"ordinal":"13"},"recipientCol":{"visible":fa\
> lse,"ordinal":"15"},"junkStatusCol":{"visible":true,"ordinal":"17"},"receivedC\
> ol":{"visible":false,"ordinal":"35"},"dateCol":{"visible":true,"ordinal":"19"}\
> ,"statusCol":{"visible":false,"ordinal":"21"},"sizeCol":{"visible":false,"ordi\
> nal":"23"},"tagsCol":{"visible":false,"ordinal":"25"},"accountCol":{"visible":\
> false,"ordinal":"27"},"priorityCol":{"visible":false,"ordinal":"29"},"unreadCo\
> l":{"visible":false,"ordinal":"31"},"totalCol":{"visible":false,"ordinal":"33"\
> },"locationCol":{"visible":false,"ordinal":"37"},"idCol":{"visible":true,"ordi\
> nal":"9"}})>[1:^9F(^B6^93)]

It may be an incompatibility of .msf data, and this kind of incompatibility may be a cause, because problem looks observed mainly upon software update.
(In reply to WADA from comment #69)
> (In reply to annihilannic from comment #68)
> > Do you have a link to an 11.0.0 installer?
> 
> http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/
> Oh, Tb 12.0(.0) looks released.

NOt yet still in 48 hours , but we are ready :-)
I have this issue with all recent versions of TB up to and including 12.0.1 - on both of my PCs. 
I'd love to see this solved as it is quite annoying.
Annoying indeed. Solution is needed

I've just marked additional getsatisfaction topics as possible matches to this bug.
tracking-thunderbird14: --- → ?
tracking-thunderbird15: --- → ?
Keywords: qawanted
Whiteboard: [gs] → [gs][addon: test pilot?]
There are many reports of this (in bugs).

Why is there suspicion it has something to do with Test Pilot?
That was my suspicion in bug 724854 (and I see the issue again despite the last comments in that bug).
And is it confirmed in any way? Does it help to disable it?
I see the problem (just changing columns even without update) myself so can try it.
It seems many users in the GS link (in URL) confirm it helps.
(In reply to :aceman from comment #77)
> And is it confirmed in any way? Does it help to disable it?

What's reported is a mixed bag. Some report it without TP.  But some report it only with test pilot enabled - https://getsatisfaction.com/mozilla_messaging/topics/folder_columns_wont_stay_set_keep_reverting_to_some_non_default_configuration

I haven't determined which describes my situation.
And some gfsn topics have no feedback yet.
OK, I could consistently observe this:
1. I have one folder with a special set of columns (with even custom columns like glodaID).
2. Usually everything is OK and the set is remembered between restarts.
3. But sometimes the Status column reappears in the set, which should not be there. I could not link it to any particular event so far. Sometimes I do not notice the new column for several days (it may be there I just do not notice).

So what I tried now:
4. disable Test Pilot (TP). Set columns to wished state.
5. Restart, all is OK.
6. Restart, all is OK. Enable TP.
7. Restart, Status reappears. (this happened every time in my several cycles of this test).
8. Set columns to wished state.
9. Restart, all is OK.
10. disable Test Pilot (TP).
11. Restart, all is OK.
12. return to point 6.

So for me the event of enabling Test Pilot consistently breaks the columns.

On the other hand, I do not know what is the event, that triggers it randomly (like once a week). I do not have automatic updates of TB or extensions enabled. Maybe TP is downloading some new surveys/date and reinitializes itself, causing the columns problem? But I haven't seen any surveys.
I have just reproduced this as well.  

I disabled Test Pilot earlier today just because I wanted to see if it would make any difference.  No issues with Test Pilot disabled.  Upon reading :aceman's Comment 80, I decided to enable Test Pilot.  As soon as I restarted TB after enabling Test Pilot, my "From" column reverted to "Recipient"

Needless to say, I have now disabled Test Pilot once again.
I found this bug with no Test Pilot installed. Installing and deinstalling Test Pilot makes no difference. For me the bug is triggered by restart after addon update or TB update.
I have observed the "column reset" (more correctly .msf corruption) issue for several weeks now.  It seems like about the time 12.0.1 came along, but I am unable to confirm that actual point in time.  

I am running TB 12.0.1 on OS X 10.7.4, with two add-ons only (Enigmail and Display MUA; the behavior persists with those add-ons removed).

I keep all folders' column view set to the same non-standard set.  Occasionally, on restart of TB, one or more of these folders will be reset to the default column set.  I have tracked the .msf files at times, and caught one or two on occasion when TB has just been closed.  The block of text that describes the column layout is missing, and I know then that that folder's columns will be reset when I restart TB (and it is).  There may be other corruptions in the .msf file, too, but I don't know enough about its layout to say that.

It appears TB is not correctly writing the .msf file, or even actively corrupting it, for some reason.  The folders that get changed are always ones I've been working with, reading and deleting mail and emptying its corresponding Trash folder.  But I have been unable to pin down an exact sequence that will cause the .msf corruption.

I have tried removing add-ons (as mentioned above), repairing the folder, compacting the folder.  Then, one or three restarts later (or any other random number of restarts later), one or more folders have their columns reset again.
Thanks a lot Henry for this detailed report. It corresponds exactly to what I have been observing for a while (see bug 750251 for my report).
@aceman what may be useful is to see if we can get a try server build which produces some logging of the values saved and restored in the database and see if there's a case where we're not always saving the changed values, or maybe there's some compaction or something that causes the msf to be rewritten incorrectly. Having some logging here might help us.
I noted this problem (not sure if I was the first or one of many and created a duplicate bug) but... It was mentioned back a ways that turning off TEST PILOT solved the problem. I stopped using TEST PILOT on May 3, 2012 and today received the first update since turning it off for TB 13.0. After the update, the columns which included 'From' in the Inbox remained as is. This means the other person's thoughts that TEST PILOT is the culprit is correct.
I experience the problem of .msf files being corrupted (as I noted above), yet I have never used Test Pilot.  In fact, I've never even heard of Test Pilot until reading this thread.
When are your msf files corrupted?
By corrupted, I assume you mean the column persistence code is writing the wrong values into the .msf file, or clearing out the existing values. It's highly unlikely that the .msf files themselves are corrupt.

Is it possible the .msf files are getting regenerated, by reparsing the mailbox folder?
Exactly, the column persistence code is being written incorrectly, and the folder reverts back to the default set of columns.  If I catch a folder at just the right time (view it in a text editor), I can see the column persistence code has changed.

If I could tell you exactly *when*, we would have something.  From this (primarily) end-user standpoint, it appears random, though it is not.  Some "messing around" with the folder always precedes the change, such as reading/deleting mail, and emptying the trash folder corresponding to that folder.   It has never happened to a folder that was untouched before closing Thunderbird.

But so far, though I have tried, I cannot duplicate a set of actions that will result in the problem 100% of the time.  Opening Thunderbird is now like a treasure hunt, to see which (if any, sometimes none) of the folders have had their columns reset.
(In reply to :aceman from comment #89)
> When are your msf files corrupted?
As for me, I have 100% hit when TB is restarted after any addon update.
New information, (news to me, anyway).  I have just experienced a folder's column view being reset to default while Thunderbird was open.  I *thought* before it was only happening on a close and reopen of the program, based on my single experience here with 30-some folders.

I had been working in the folder in question earlier, simply reading messages and deleting them, and then put the focus back on my Inbox before walking away.  On my return, and my return to this particular folder, its column view is set back to default.  The default column view is very different than what I prefer, so it is immediately apparent.
(In reply to henry from comment #93)
> I had been working in the folder in question earlier, simply reading
> messages and deleting them, and then put the focus back on my Inbox before
> walking away.  On my return, and my return to this particular folder, its
> column view is set back to default.

One other thing I might add, is that messages are shunted into this folder via a message filter, and new messages had arrived while I was away from the computer.
Henry, are these local or imap folders?
They are all local folders.  I have three POP accounts set up (ISP, GMail, and a local network server), and a "Sorted" container that holds a couple of dozen local folders as well.  All POP accounts delete mail on the server as they go.
I've set a breakpoint on the code that sets the columnsState in the db. In general, it never gets called, unless folder compaction or repair is invoked, and in that case, it maintains the previous settings. I've also experimented with the "apply current columns to folder hierarchy" feature. It does apply the current columns to all the folders, except for the saved searches, which looks to be a bug in MailUtils_setStringPropertyOnFolderAndDescendents, which skips folders that can't have messages filed in them.

However, I'm now in a mode, or perhaps it's just some folders, that when I click on them, a FolderLoaded event is sent, and then eventually the front end sets the column state. I'm not sure what's causing this...perhaps there's no db for these folders, though that would be surprising. I'll poke around a bit more.
From what I can tell, for most folders (not saved searches or news folders or the outbox), if we don't have columns for a folder, we'll inherit them from the inbox in the same account. Does your inbox folder have the right columns set? Do you ever open folders or messages in other windows or tabs?

These are the default columns (depending on the folder type). Are they the values you're getting reset to?

    "threadCol",
    "attachmentCol",
    "flaggedCol",
    "subjectCol",
    "unreadButtonColHeader",
    "senderCol", // incoming folders
    "recipientCol", // outgoing folders
    "junkStatusCol",
    "dateCol",
    "locationCol", // multiple-folder backed folders
One more question, when this happens, Henry, can you look at the error console (tools, error console) and see if any new errors were added at the time it happened?
(In reply to David :Bienvenu from comment #98)
> From what I can tell, for most folders (not saved searches or news folders
> or the outbox), if we don't have columns for a folder, we'll inherit them
> from the inbox in the same account. Does your inbox folder have the right
> columns set? Do you ever open folders or messages in other windows or tabs?

Yes, the list of columns you provided is what I get reset to when they reset.  My preferred layout, (which I keep set for every folder, including Inboxes, Drafts, Templates, Trash, Sent and my "saved mail" folders, is
"attachmentCol"
"senderCol"
"recipientCol"
"subjectCol"
"dateCol"
"sizeCol"

I rarely search, never save searches, have no news accounts, use one tab only in the main layout, and messages open each in their own window.  I don't use the tab feature at all, except that I have to have one of them.  Sometimes a picture communicates better than I can:  http://www.hup.org/misc/Thunderbird-layout.jpg

I saw mention earlier of the error console, and just plain forgot to check it.  I will make sure to do so the next time this happens.
(In reply to David :Bienvenu from comment #98)
> These are the default columns (depending on the folder type). Are they the
> values you're getting reset to?

It's interesting that the defaults depend on folder type.  When I encounter this problem my Inbox columns seem to be set to the default for an outgoing folder rather than an incoming one, i.e. I have a "Recipient" column where I expect the "From" column to be.  I use a global Inbox for 4 POP3 accounts.  Perhaps it thinks incorrectly that my Inbox is an outgoing folder for some reason?
(In reply to David :Bienvenu from comment #99)
> One more question, when this happens, Henry, can you look at the error
> console (tools, error console) and see if any new errors were added at the
> time it happened?

It just happened.  The immediate set of actions that preceded it were:
1. browsing in Main Inbox, deleted one message (all is well, column-wise)
2. right-click on the corresponding Trash folder, select "Empty Trash"
3. return to Inbox, columns have been reset to the default view

There is nothing new in the error console.

At one point (a few days ago), I was sure this was a way to bring on the error.  But since then, I have repeated the steps quite a few times, and for the most part it does not error.  It is frustrating not to be able to pin down a cause-effect.
(In reply to henry from comment #102)
> It just happened.  The immediate set of actions that preceded it were:
> 1. browsing in Main Inbox, deleted one message (all is well, column-wise)
> 2. right-click on the corresponding Trash folder, select "Empty Trash"
> 3. return to Inbox, columns have been reset to the default view

For #3, what do you mean by 'return to inbox'?  Did right-clicking on the trash change the trash folder to be the active folder, or had the message list transitioned to some other folder?

Also, do you know if when Thunderbird had asked you if it was okay to compact folders, you checked the box that says it should just automatically do it without asking?  It's conceivable there's a race related to compaction, which would also explain why this does not happen consistently.
By "return to Inbox", I mean to say put the focus back on the Inbox.   You are correct, right-clicking (command-clicking) on the Trash does not give it the focus, and you can empty the Trash that way.  However, in this case I did give the Trash the focus first, to see what it had, then right-clicked to empty, then returned the focus to the Inbox, where my columns were now reset to the defaults.

As for compacting, it never asks me.  I have the check box checked to compact whenever it will save 1MB (the minimum).  There was nowhere near 1MB in the Inbox or Trash today; there rarely is.  That usually applies to my saved mail folders only.

I really appreciate this follow-up on your part.  Before retiring I admin'ed and supported a variety of servers, but I am no programmer and have never had to support a software program.  Your questions remind me just how varied the possible configurations are for something like Thunderbird.  As an end user, I tend to assume that my configuration is "typical", but it is not, I can readily see.
Honza's db log shows NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE for the INBOX, on startup. Even in that case, we should restore the column settings to the new db from the out of date db, unless we could not read the db at all.

Re Henry's comment about getting the Sent folder columns for his inbox when the columns reset, that's interesting, but I'm not quite sure what to make of it. If you look at the sent folder setting for your various accounts, none of them point at the inbox, do they? One thing about the sent folder flag is that it does tend to be inherited, in that sub-folders of the folders marked as sent folders are considered to have the flag.

Also, Henry, if you look in the config editor, (tools, options, advanced, general, config editor button), what is the value for mail.prompt_purge_threshhold ? If false, we won't prompt you for compaction, and will just silently do it.  If compaction is indeed involved, raising the threshold from 1MB to 100MB should reduce the frequency of the issue, and might be an interesting test.
Two things.  First, that was someone else who said he gets the Sent column defaults when he gets reset.  To tell the truth I never bothered to notice which of those two defaults I get reset to (incoming or outgoing folder).   I will definitely take note on the next occurrence.

So, the prompting for compacting setting is tucked away in prefs.js.  My value for mail.prompt_purge_threshhold is set to "true".  It should be prompting me before it compacts?  I do not recall the last time I saw a prompt, and based on the volume of mail I handle (low volume, small sizes), I probably have satisfied the compaction algorithm by occasionally manually compacting (sort of twiddling my thumbs).  I suppose that means that, for me anyway, compacting is not entering into the picture?  At any rate, I raised my "Compact folders when it will save over" from 1MB to 100MB.
FYI.

(In reply to henry from comment #106)
> My value for mail.prompt_purge_threshhold is set to "true".
> It should be prompting me before it compacts?

Confusing but following is currently used.
> mail.prompt_purge_threshhold = true/false  <= true : auto-compact is enabled
> mail.purge_threshhold_mb     = NN          <= threshold value in MB 
> mail.purge.ask               = true/false  <= true : prompt before auto-compact
It's perhaps for historical reason like, prompt_purge_threshhold=true prompted always initially, the prompting was removed in the past, and prompting came back by mail.purge.ask.
After setting change of mail.purge.ask, "restart of Tb" is curretly mandatory.
(In reply to David :Bienvenu from comment #105)
> Re Henry's comment about getting the Sent folder columns for his inbox when
> the columns reset, that's interesting, but I'm not quite sure what to make
> of it. If you look at the sent folder setting for your various accounts,
> none of them point at the inbox, do they? One thing about the sent folder
> flag is that it does tend to be inherited, in that sub-folders of the
> folders marked as sent folders are considered to have the flag.

I've never noticed before, but of my 5 POP3 accounts, 3 are configured like this:

When sending messages, automatically
[x] Place a copy in:
  [x] "Sent" Folder on [Local Folders v]
  [ ] Other            [Sent          v]

And the other 2 like this:
  
When sending messages, automatically
[x] Place a copy in:
  [ ] "Sent" Folder on [Local Folders v]
  [x] Other            [Sent          v]
  
... but I'd expect the end result to be the same.  The "Drafts" and "Templates" folder settings follow the same pattern.  My Sent folder does not have any subfolders that are likely to have inherited the flag.

For completeness, my compaction settings are:

mail.prompt_purge_threshhold;true
mail.purge.ask;false
mail.purge_threshhold_mb;4
My main Inbox just had its columns reset to the default set again, and it is definitely the default set for an incoming folder, not an outgoing folder.

Here's what led up to this:
1. yesterday I set up compacting as follows:
    mail.prompt_purge_threshhold = true
    mail.purge_threshhold_mb = 1
    mail.purge.ask = true

This morning, I received a prompt asking if I wanted to compact, and I said yes.  Initially, the Inbox seemed OK, but when I navigated away from it (put the focus on other folders), and then put it back into focus, it was reset to the default column view.

The error console contains a number of events from two hours ago, nothing with the timestamp of this event.  The messages two hours ago were a set of warnings, and a set of errors.

The warnings:

Timestamp: 5/25/12 5:09:40 AM
Warning: Unknown property 'homa-weight'.  Declaration dropped.
Source File: mailbox:///Volumes/hephaestus/ApplicationSupport/Thunderbird/Mail/Main/Inbox?number=294774
Line: 85
Timestamp: 5/25/12 5:09:40 AM
Warning: Unknown property 'xposition'.  Declaration dropped.
Source File: mailbox:///Volumes/hephaestus/ApplicationSupport/Thunderbird/Mail/Main/Inbox?number=294774
Line: 94
Timestamp: 5/25/12 5:09:40 AM
Warning: Unknown property 'xheight'.  Declaration dropped.
Source File: mailbox:///Volumes/hephaestus/ApplicationSupport/Thunderbird/Mail/Main/Inbox?number=294774
Line: 113
Timestamp: 5/25/12 5:09:40 AM
Warning: Unknown property 'xborder-bottom'.  Declaration dropped.
Source File: mailbox:///Volumes/hephaestus/ApplicationSupport/Thunderbird/Mail/Main/Inbox?number=294774
Line: 113
Timestamp: 5/25/12 5:09:40 AM
Warning: Unknown property 'xmargin-bottom'.  Declaration dropped.
Source File: mailbox:///Volumes/hephaestus/ApplicationSupport/Thunderbird/Mail/Main/Inbox?number=294774
Line: 113
Timestamp: 5/25/12 5:09:40 AM
Warning: Error in parsing value for 'padding'.  Declaration dropped.
Source File: mailbox:///Volumes/hephaestus/ApplicationSupport/Thunderbird/Mail/Main/Inbox?number=294774
Line: 118    

The errors (there were six, identical to this one except for relating to different images embedded in the email):

Timestamp: 5/25/12 5:09:42 AM
Error: Image corrupt or truncated: http://pr.ak.vresp.com/06acb23f3/www.thetoolwarehouse.net/images/Product/medium/EQS-3160.jpg
Source File: http://pr.ak.vresp.com/06acb23f3/www.thetoolwarehouse.net/images/Product/medium/EQS-3160.jpg
Line: 0

Because of the timestamp proximity between the warnings and errors, I suspect they both relate to the same message that arrived in my Inbox.  However, I no longer have that message.
My guess at this point is that you are attempting to re-display the folder while compaction is ongoing.  DBViewWrapper doesn't have unit tests involving compaction for this case, so it would not be tremendously surprising.

The good news is that we do not appear to call stalkFolders (which will net us the CompactCompleted) notification until after we have successfully entered the folder.  This suggests that one of the following is happening:

- We are able to enter the folder when it is compacting because there is a msgDatabase, but its state is now wonky.
- Some kind of race occurs with the folder loaded notification and we win it before the db folder info gets copied over.
- shouldShowMessagesForFolderImmediately tells us to enter the folder immediately and so onDisplayingFolder (which will set up new defaults) runs prior to onLoadingFolder (which loads the persisted settings)

I don't think the DBViewWrapper should be checking the folder semaphore, but we definitely don't.
(In reply to Andrew Sutherland (:asuth) from comment #110)
> My guess at this point is that you are attempting to re-display the folder
> while compaction is ongoing.

I am not sure I understand all of what you said, but it suggests to me a reasonable explanation for the .msf being reset to default.  That would also explain why, earlier, I was convinced that emptying Trash had something to do with it.  Since I had mail.purge.ask set to false earlier, there was some compacting going on behind the scenes when I did empty the Trash, but I just didn't know it?

This morning, with mail.purge.ask set to true, there was a definite chain of events: answer "yes" to the compact prompt, and then interrupt the process by viewing the folder again too soon?

I am supposing that if you have mail.purge.ask set to false, then there is also some compacting being done (if needed) when Thunderbird is started up.  And if it immediately tries to display the Inbox on startup, that could also be the cause of the .msf reset as well, which I (and others) have noted on program restart.
I've tried this a few times, compacting the inbox and then selecting it. I haven't been able to reproduce any issues. I also tried shutting down, invalidating the db by changing the inbox folder size, and restarting, so we reparse the folder on startup. column settings were remembered.

Starting a compact shouldn't leave the database in a wonky state. Compact doesn't touch the original database until the whole compact is finished, and then it copies the new db on top of the old database. Changes made to the columns while compact is going on wouldn't get remembered, but I don't think that's what is being described here.

Henry, if you can find some steps that reliably reproduce the issue for you, I can drill down further.
(In reply to David :Bienvenu from comment #112)
> Henry, if you can find some steps that reliably reproduce the issue for you,
> I can drill down further.

Thanks.  I know what you need all too well.  If I can figure out how to reproduce the problem at will, I will post it.
Just to chime in.  Since I disabled Test Pilot over three weeks ago I have not had one instance of this issue.  I would think that there must be some association involving Test Pilot somehow.
As suggested by WADA in comment #67, I have captured a Process Monitor log (filtered by "thunderbird.exe") which covers a simple restart of ThunderBird 11.0.1 with an undesirable reset of my Inbox columns.

I have also captured an update from 11.0.1 to 12.0.1 with a similar column reset using DebugViewer (once I figured out that I could only run one of Process Monitor or DebugViewer at a time).

The result is an 11MB encrypted zip file; I'd rather not publish it on here due to the many email addresses and other private information therein; should I send it to your mozilla.com mailbox David?

Apologies for the delay doing this... been busy.
(In reply to Rich from comment #114)
> Just to chime in.  Since I disabled Test Pilot over three weeks ago I have
> not had one instance of this issue.  I would think that there must be some
> association involving Test Pilot somehow.

Same for me. Maybe there are different bugs. Or on the other hand, maybe Test Pilot also has the trigger to reset the columns that henry triggers in other way.
(In reply to David :Bienvenu from comment #112)
> I've tried this a few times, compacting the inbox and then selecting it.
> I haven't been able to reproduce any issues.

David, I could observe "reset to default column of Inbox" by next test during test for bug 754301.
(1) Big Inbox(near 4GB), change to non-deault column selection. 
    Shift+Delete mails, Compact, because mails can't be added due to 4GB limit. 
(2) While Compact was in progress, delete panacea.dat, Get Msgs
    (Leave messages on server, mailnews.downloadToTempFile=true in this test)
    => Compact looked to terminate silently.
    => Exception at error Console was shown.
(3) After it, Exception at Error Console upon each mouse hover on Inbox.
    This is an indicator of out-dated-msf condition.
> Timestamp: 2012/05/27 17:23:17
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80550005 [nsIMsgFolder.msgDatabase]"  nsresult: "0x80550005 (<unknown>)"
> location: "JS frame :: chrome://messenger/content/mailWidgets.xml :: parseFolder :: line 2393"  data: no]
(4) Because Tb did do nothing by Get Msg or folder click
    and internal rebuild-index of Inbox was not invoked,
    I termiated Tb.
    => No column setting was saved in Inbox.msf file.
(5) Restart Tb, Inbox was selected since initial or Inbox was clicked(not sure)
    => Rebuild index was automatically invoked.
    => Following error was shown at Error Console.
> Timestamp: 2012/05/27 17:23:13
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80550005 [nsIMsgFolder.msgDatabase]"  nsresult: "0x80550005 (<unknown>)"
>  location: "JS frame :: chrome://messenger/content/folderDisplay.js ::
> FolderDisplayWidget__persistColumnStates :: line 482"  data: no]
(6) Aftr end of rebuild-index, column was set to default of Inbox.

Above is rough test scenario and is not accurate and not mandatory STR, and it's similar to "kill of Tb" from perspective of ".msf file".
But it indicates that something wrong may occur when contention between Compact and other operations happens, and that out-dated-msf condition may be generated in such situation.
(In addition to comment #117)

Above errors/phenomeno is timing dependent.
  Any of (a) POP3 download to Inbox, (b) Rebuild-Index, (c) Compact 
  normally locks out each other usually.
  If (a) is running, (b) & (c) is not invoked by "other process running" msg. 
  If (b) is running, (a) & (c) is not invoked by "other process running" msg. 
  If (c) is running, (a) & (b) is not invoked by "other process running" msg. 
So, reproducing of exceptions is hard, except error message at Error Console upon mouse hover while rebuild-index is running or while out-dated-msf conditin exists, although "silent filter move failure"(known issue) can be observed frequently by interfere of Inbox or "filter move target folder" by Compact or Rebuild-Index(Repair Folder).
Not tracking for 13 now, as we've not worked out the ways to reproduce it yet. Once we can do that and get a fix, then we'll get it into a release as soon as is reasonable for the patch.
tracking-thunderbird13: ? → -
(In reply to Mark Banner (:standard8) from comment #119)
> Not tracking for 13 now, as we've not worked out the ways to reproduce it
> yet. Once we can do that and get a fix, then we'll get it into a release as
> soon as is reasonable for the patch.

I am able to reproduce, but not reliably, and I know that is what you need.  I will however add one observation from playing around with settings over the weekend.  Every time it happens to me, it has been related to compacting, when I compacted the folder, TB compacted it for me, or even when I changed the compacting settings (tick or untick the box to compact and save space, or even change the MB size to trigger compacting).  All of these actions have resulted in my Inbox's column views being reset to default.  Unfortunately, none of these actions will make it happen every time.  There seems to be an elusive thread there that is related to compacting.
examples that don't involve test pilot seem to be in the majority and no doubt caused by compact
Frequency should be reduced, not necessarily eliminated, by bug 725810 .
Depends on: 725810
(In reply to Mark Banner (:standard8) from comment #119)
> Not tracking for 13 now, as we've not worked out the ways to reproduce it
> yet. Once we can do that and get a fix, then we'll get it into a release as
> soon as is reasonable for the patch.
I have the way to repdroduce the bug, at least it always works for me:
1. Change number of shown columns in INBOX
2. Update any of your addons, so that TB requires restart
3. Restart TB (press 'restart now' in addons manager)

Another way is just press 'repair folder' in INBOX properties. Both works for me every time.
Is any of you using a Thunderbird language version that is not English?
(In reply to :aceman from comment #123)
> Is any of you using a Thunderbird language version that is not English?
I use English TB on Russian Windows 7.
Flags: in-testsuite?
Flags: in-litmus?
I have tinkered with this bug, now running 13.0.1, and I am able to reproduce it at will, now, here.

1. set mail.purge_threshhold_mb     =  some large number, so purging does not happen by itself; I use 30MB on my system

2. set mail.server.serverx.empty_trash_on_exit  = true, for all accounts/servers.  I believe, but cannot confirm because I don't know the underpinnings of Thunderbird, that manually emptying trash by highlighting a trash icon and choosing (right-clicking or menu) "empty trash" also triggers some sort of compacting mechanism, especially on the folder where the trashed messages came from.  This behavior resulted in some folders having their column views reset on an irregular basis (not 100% repeatable, at least for me), so setting to empty trash on exit seems to have stopped this part of it and eliminated this part of the behavior from the equation

3. wait until the Inbox needs compacting (check file on disk that it has grown).

4. exit Thunderbird (to empty the trashes), and reopen.  I am not sure this step is necessary

5. manually invoke a compact (right click folder or container, or highlight and use menu choice).

The Inbox will now have its column view reset to the defaults for an incoming folder.  It does not happen immediately, but pretty quickly.  Either navigate away from it (by putting the focus on another folder) and then return to it, or simply close Thunderbird and reopen it.

I am able to do this with 100% repeatability here.
I have had the problem in TB for several months - I think from Version 6.

Like some of the above correspondents, I observed the problem only intermittently. But I've now discovered that it always occurs when all the following conditions are satisfied:

(1) The folder has deleted items; (2) the folder is compacted; (3) the number of remaining items in the folder is 1 or 2; (4) Thunderbird is restarted.

The column headings in that folder after the restart are the ones from Inbox, or, if the folder itself was Inbox, some default settings.

Yes, I know it's unbelievable, but I've done dozens of trials, and it's consistent. It explains why the problem (for me) seemed to occur at random, and usually with Inbox. I compact Inbox every evening before backing up and shutting down, and the number of items it contains varies between 0 and about 10. I've never observed the problem when the number of remaining items is 0 or more than 4. It /sometimes/ occurs with 3 or 4 items.

After writing the above, I began to wonder what the 'default' settings are, so I tried 'Reset columns to default' (which I'd never used before, as I assumed the default would not be what I want). I found that this sets the headings as described above - i.e., to the current 'Inbox' values, except for Inbox itself.
There are reports in bug 749574 (which is very similar), that this seems fixed in TB14. Can anybody try it out?
See Also: → 749574
Well, it happened just now as I updated to 14... however that could be because the bug was encountered as 13.0.1 was shutting down for the update.  I'll report if it happens again while running 14.
can you reproduce under these conditions
- set column, and use "apply columns to folder" ...
- folder has no deleted items
- no compact is done
- restart
If it might help track down the problem, in a backwards sort of way, I have reverted to 10.0.2, and the problem is definitely absent there.   I have tried every known behavior to make the column reset happen in 10.0.2, and it will not do it.  I have been back on 10.0.2 for two weeks now.

This jives with my noticing the problem after upgrading to (either) 11, or 12, I cannot say for sure which one brought it on.
(In reply to henry from comment #131)
> If it might help track down the problem, in a backwards sort of way, I have
> reverted to 10.0.2, and the problem is definitely absent there.   I have
> tried every known behavior to make the column reset happen in 10.0.2, and it
> will not do it.  I have been back on 10.0.2 for two weeks now.

Interesting.  Unfortunately that doesn't jive with Honza's experience.

Anyway, you could test some early version 11 buiulds to see when the bug fist appears.
ftp://ftp.mozilla.org/pub/thunderbird/releases/11.0b1/ 
ftp://ftp.mozilla.org/pub/thunderbird/releases/11.0b2/
Has anyone tried the STR successfully in comment 126?
(In reply to Kent James (:rkent) from comment #133)
> Has anyone tried the STR successfully in comment 126?

I have never been able to reliably reproduce this, but my theory is that it's associated to a core shutdown problem fixed only on trunk.
See:
bug 758826
bug 763361

If the settings are not being saved on shutdown, then strange things happen.
Bug still present in TB 15.
I can confirm, the bug still exists in TB 15.
Another confirmation that the bug still exists in TB 15.  

This occurs whether or not a manual adjustment has been made to the columns; the "Recipient" column serves no purpose in the recipient's In Box.

Further information:

http://forums.mozillazine.org/viewtopic.php?f=39&t=2483219
http://forums.mozillazine.org/viewtopic.php?p=3287926#p3287926
http://forums.mozillazine.org/viewtopic.php?p=76963#p76963
http://forums.mozillazine.org/viewtopic.php?f=31&t=2430683
https://bugzilla.mozilla.org/show_bug.cgi?id=710056
https://bugzilla.mozilla.org/show_bug.cgi?id=550286

Pertinent Highlights:

"We have 2 staff out of 200+who have complained about this, there will be several more who are too busy or scared to call."

"This bug is difficult to search on as the word 'from' is so common in ordinary sentences."

"Further testing has revealed that the Inbox that has the Read column removed and the Recipient column put in it's place every time you start Thunderbird is the Inbox you were viewing when you closed down."

"The bug seems to happen either on startup or shutdown, as it targets the folder in play at the time."
annihilannic, Fernando, chibiakujin,
There's no need to re-confirm this with every release. Don't expect this to be fixed in any future release until this bug is marked as fixed (which usually requires that someone submit a patch and the patch get applied to the Thunderbird code).

Until that happens, you can assume this bug will be present in version 16, 17, and so on.
What WILL be useful is to try the steps to reproduce in comment 126, and confirm if that works for you to reliably reproduce this bug. Or do your own STR. There are plenty of developers watching this bug, but nobody has been able to reproduce it reliably, which is the first step to a fix.
Chris, actually this could be fixed without anybody marking it here because we don't know yet what causes it, so it may happen that it is incidentally fixed in other bug.
I understand that, but the point is that there is no need to post a comment every time a new version of Thunderbird is released. Expect the bug to be there. If it is not, then there is reason to post a comment.
Kent James wrote (comment #139):

> What WILL be useful is to try the steps to reproduce 
> in comment 126, and confirm if that works for you to 
> reliably reproduce this bug.

Has anyone tried the method I gave in comment 127, which seems simpler? Here's a recipe that avoids experimenting with your existing folders.

1. Create a new folder. It will have the same columns as Inbox.

2. Make a change in the columns.

3. Copy 2 emails into the folder.

4. Delete one of these emails.

5. Compact the folder.

6. Exit Thunderbird.

7. Restart Thunderbird. The columns revert to the Inbox columns.
Solid steps are great. But it is often the case that devs can't reproduce when user can even with solid STR. In which case, it may be necessary to provide the full profile where the problem is observed.
Mike, I can reproduce with the steps from comment 142, on TB18 Win XP. Even if I exit TB after step 4. and start TB and see the columns are OK, then after steps 5.-7. the columns get reset. So it seems the compaction operation is a problem here.

However these steps do not match with the original bug summary as filed. I think there was another bug about this where it was not tied to Testpilot and TB updates. Can we find it?
Whiteboard: [gs][addon: test pilot?] → [gs][addon: test pilot?][STRs in comment 142]
Mike, thanks for the steps to reproduce. Based on them I've found that when the columns are changed, custom column entries get added to the mail folder's .msf file; after the compact, the custom columns are missing (even before TB is shut down and restarted). I'll dig into the code now and see if I can spot where that happens.
Assignee: nobody → irving
Status: NEW → ASSIGNED
xpcshell test that shows columns persisted in the database before a compact, and missing after
Attachment #662278 - Flags: review?(kent)
Comment on attachment 662278 [details] [diff] [review]
xpcshell test that demonstrates the failure

Looks OK. Just one issue. Standard8 convinced me years ago to stop naming tests for bugs, and I agree with him now. Could you give this a descriptive name rather than a bug number?

Of course this should not be checked in until after the fix, which I will post shortly.
Attachment #662278 - Flags: review?(kent) → review+
Most of the discussion of this issue is in the duped bug 750569

Irving, feel free to give the review to bienvenu if you don't feel comfortable.
Attachment #663482 - Flags: review?(irving)
Attachment #663482 - Flags: feedback?(mozilla)
It would be great to push this to a TB 16 beta when appropriate - and we definitely want it in TB 17. This could fix the root cause of a lot of folder compact grief, but any changes in this area are not without risk.
tracking-thunderbird16: --- → ?
tracking-thunderbird17: --- → ?
Assignee: irving → kent
Kent, I really intended the db's to only get closed after 3 minutes of idle (or 5, I can't remember), not 3 seconds. It was a milliseconds vs. seconds confusion, so that really should be fixed.
(In reply to David :Bienvenu from comment #151)
> Kent, I really intended the db's to only get closed after 3 minutes of idle
> (or 5, I can't remember), not 3 seconds. It was a milliseconds vs. seconds
> confusion, so that really should be fixed.

Pref looks to be intended to be 5 minutes. But code doesn't net out to be, anso d dbs may be closing too quickly

  // How long should we leave idle db's open, in seconds.
  pref("mail.db.idle_limit", 3000);  (intended to be 5 min, per comments)

  attribute PRTime lastUseTime; (microseconds)

  let idleLimit = Services.prefs.getIntPref("mail.db.idle_limit");
  let closeThreshold = Date.now() - idleLimit; (microseconds)
...
      let lruTime = db.lastUseTime / 1000;  microseconds/1000 = tenths?
      if (lruTime < closeThreshold)
        db.folder.msgDatabase = null;
Comment on attachment 663482 [details] [diff] [review]
Add db to cache in SetSummaryValid

Review of attachment 663482 [details] [diff] [review]:
-----------------------------------------------------------------

nit: The patch comment doesn't describe the contents

Just to make sure I understand what's happening, compared to your earlier patch on bug 750569: by making sure new DB is in the cache once it's valid, when nsFolderCompactState::FinishCompact() calls mFolder->setDBTransferInfo() it gets the new DB from the cache instead of creating a new instance, and that's why we don't need to mFolder->setMessageDB() like your first WIP patch did?

If that understanding is correct, then r=me with the comment fixed for trunk but I'd like to get at least feedback, if not super-review, from David before it goes to Aurora.
Blocks: 793455
No longer blocks: 793666
Re comment #151/152, please follow bug 793455.
irving: re "Just to make sure I understand what's happening ..." Yes your understanding is correct. Getting the db defined on the folder is not reliable for two reasons: 1) other code tends to delete that reference randomly. 2) Not all database opens check the folder reference first, while all code checks the cache reference. So it is critical that the cache is correct to prevent opening of multiple databases on the same folder.
Comment on attachment 663482 [details] [diff] [review]
Add db to cache in SetSummaryValid

Checked in (with correct message) http://hg.mozilla.org/comm-central/rev/3ee190555c32
Attachment #663482 - Flags: review?(irving) → review+
Attachment #663482 - Flags: feedback?(mozilla) → superreview?(mozilla)
Attached patch Checked in test — — Splinter Review 
Patch checked in with nits fixed

http://hg.mozilla.org/comm-central/rev/46a016210d50
Attachment #662278 - Attachment is obsolete: true
Attachment #664148 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 18.0
Thanks rkent, I'll try if it fixes the Test pilot initiated column losses too.
Congrats rkent, I can't see the problem anymore with steps from comment 142 and comment 80.

Can anybody confirm?
Wayne, can you get any of the reporters having the problem caused by Test Pilot check out this TB nightly?
Whiteboard: [gs][addon: test pilot?][STRs in comment 142] → [gs][addon: test pilot?][STRs in comment 142]duptome
Comment on attachment 663482 [details] [diff] [review]
Add db to cache in SetSummaryValid

I guess this can't hurt. I think the usual way new db's get added to the cache is here:

http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#1218

But for the compact code, we must not be ending up in that case. For reparsing folders, we do.
Attachment #663482 - Flags: superreview?(mozilla) → superreview+
CheckForErrors, which does the AddToCache, is only called after a database is actually opened. So once it is opened with NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE then there is no way (without this patch) for it to ever get added to the cache.

And yes during compact NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE is true when the database is opened so AddToCache is not called.
Comment on attachment 663482 [details] [diff] [review]
Add db to cache in SetSummaryValid

[Approval Request Comment]
Regression caused by (bug #): Perhaps bug 793455

User impact if declined: Folder compact will not only lose certain kinds of data, but may have other unforeseen problems.

Testing completed (on c-c, etc.): Yes

Risk to taking this patch (and alternatives if risky): Does not seem particularly risk.
Attachment #663482 - Flags: approval-comm-aurora?
Comment on attachment 663482 [details] [diff] [review]
Add db to cache in SetSummaryValid

Accepting for Aurora. Do we also want this for beta as well? I think it should be reasonably low risk.
Attachment #663482 - Flags: approval-comm-beta?
Attachment #663482 - Flags: approval-comm-aurora?
Attachment #663482 - Flags: approval-comm-aurora+
(In reply to Mark Banner (:standard8) from comment #163)
> Comment on attachment 663482 [details] [diff] [review]
> Add db to cache in SetSummaryValid
> 
> Accepting for Aurora. Do we also want this for beta as well? I think it
> should be reasonably low risk.

We do, that would give us the 16 cycle to discover side effects if any and that will make 17 way more stable for our users.
Yes I also think it is fairly low risk and high benefit, so adding to beta would be good.
Attachment #663482 - Flags: approval-comm-beta? → approval-comm-beta+
The problem appears to have come back in TB 16.02 but not consistently. Seems to occur on some folders and not others as well as Inbox for some accounts and not others. I still have to keep resetting the columns shown but not every time it is brought up.
(In reply to Hillel Markowitz from comment #171)

I haven't noticed any problems in TB 16.02. In particular, the procedure given in Comment 142, which reliably reproduced the problem before it was fixed, doesn't show the problem.
I am looking at the problem right now. Thunderbird 16.02 Window 7 64 bit. The Inbox shows recipient and not From.
It steal happens to my users in TB 16.0.2
The issue that was fixed in this bug was a real problem, and therefore solved the symptoms for many users.

There is a natural progression in a bug's life, starting with a symptom, and ultimately morphing into the resolution of a specific problem. This bug has now morphed beyond being defined by the symptom, and is more defined by the problem that it solved.

So if you are still seeing similar symptoms, yes it is annoying but the proper thing to do is to file a new bug, and go back to the basics of developing a reproducible test case.
As the issue is here for me in TB 16.0.2 I filed new bug #813539
See Also: → 810682
See Also: → 550286
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: