Closed Bug 812786 Opened 12 years ago Closed 8 years ago

Inbox folder message list display sometimes drops "From" and adds "Recipient" column.

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Version:
16 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: arthur.gaughan, Unassigned)

References

Details

Attachments

(2 files)

Small test extension to show column setting value obtained via gFolderDisplay.getColumnStates(), to dump msgFolder object properties
43.60 KB, application/octet-stream
Details
Transition by restart of Tb, of gFolderDisplay.getColumnStates() of Inbox, Thread column entry in Inbox.msf
8.79 KB, text/plain
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121024073032

Steps to reproduce:

Nothing notable


Actual results:

Since I have been using T-Bird (5+ years), the inbox (and perhaps other) message display occasionally & spontaneously drops "From" and adds "Recipient".


Expected results:

When I select to display "From" in the InBox message display, it should stay that way!
If you are talking about a recent phenomenon, in the past year, one such issue was fixed in version 16. But you seem to already be running versio 16.

Do you run ccleaner?  it has a habit of killing some Thunderbird settings?
Or do you do "repairs" on folders?
Component: Untriaged → Folder and Message Lists
Summary: Since I have been using T-Bird (5+ years), the inbox (and perhaps other) message display occasionally & spontaneously drops "From" and adds "Recipient". → Inbox folder message list display drops "From" and adds "Recipient" column.
In response to Wayne Mery...

I have tried over the years to detect any correlation with actions/activity but have been unable to detect same.

I am (now) using T-Bird 16.0.2 but, as I said, this goes back a long way. It is an (now) extreme annoyance but other than trying my patience - has no other side effects.

I do not use ccleaner and I do not do "repairs" to folders. I am currently running Win7SP1 with an external monitor. Prior to Win7SP1, I ran WinXpSP3 on the same hardware - the problem existed there too.

It would seem that for the (default) inbox mesage display, "From" should be the default and not "Recipient" - I already know who I am. For the Outbox, on the other hand, "Recipient" should be the default and not "From" - for the same reason. This problem has never been observer in the Outbox message display!
Summary: Inbox folder message list display drops "From" and adds "Recipient" column. → Inbox folder message list display sometimes drops "From" and adds "Recipient" column.
How often do the columns reset and could you already correlate it to any event in TB?
I have not been able to correlate it with any particular event. I have three accounts in my folder and some folders with filters in each account besides the defaults. I have had the main Inbox change while other folders do not change.

I have also had (lately) the Recipient column return after having been removed even when the From column stays visible. I have also had the From column disappear while the Recipient column returns. However, some other folders keep the setting with the From column visible and the recipient column removed.

It appears to happen after I have logged out of Thunderbird and then reactivated it. I do tend to exit using the "corner x" rather than the File -> Exit
re: "aceman" comments - the effect is sporadic at best; sometimes weeks will pass before it recurs.

re: Hillel Markowitz comments - I have a filter on my InBox but only one account;
I can attest to all of the observations in Hillel's para #2;
I cannot attest to Hillel's observation in para #3 but - I will watch for it.

"If it's not broken, I can't fix it" would seem to apply here!
I have noticed as of the past 5 days (2/1/2013) that every time I perform a hard reboot of my (Win7Pro) system and restart T-Bird, the "From" field is disabled/removed and the "Recipient" field is enabled/inserted. If I exit T-Bird and relaunch T-Bird in between hard boots of Win7Pro, the noted behavior is intermittent. Since I normally "sleep" the system without exiting T-Bird, the above noted behavior is not observed when the system emerges from "sleep". I hope this helps. I am running T-Bird 17.0.2 & Win7Pro SP1.
Even if column setting is somehow lost and deault is set, and if it happens on Inbox, applied default should be one for Inbox == with From, without Recipient. "Without From, with Recipient" is internal default for "Sent".

Do you set Sent==Inbox or you used Sent==Inbox setting in the past?

When Sent flag=on && Inbox flag=on, API returns Inbox flag only in order to use the Inbox folder as Inbox(To was hidden, From was shown) instead of Sent(From was hidden, To was shown). However, "Sent flag" itself is saved in flags data of MsgFolder.flags. So the Inbox may be considered as Sent type folder in some places.

If you used with Sent==Inbox in the past but you don't use with Sent==Inbox any more, try following to reset Sent flag of Inbox.
  0. Confirm that no identity uses Inbox as Sent. 
  1. At an identity, use Inbox as Sent, exit Account Manager.
  2. At the identity, use other than Inbox as Sent.
     (Sent flag is reset only when "setting change from Sent to not-Sent")

Do you still see "reset to without From, with Recipient"?
I have never used Inbox as Sent. All accounts use a separate Sent folder in that account.
Reply to recent "WADA" & "Hillel Markowitz" comments...

This errant behavior ONLY occurs in the "Inbox"! This NEVER occurs in "Sent"!

I agree with WADA about "expected" behavior (of the Inbox default). Thus, the observed behavior appears to violate the default for Inbox. I have NEVER used the "settings" described by WADA.
(In reply to arthur.gaughan from comment #2)
> I am (now) using T-Bird 16.0.2 but, as I said, this goes back a long way.

As known by bug 710056(Tb 16:fixed, Tb 17:fixed) and many duped bugs, major cases are already resolved by bug 710056.
This bug and bug 813539 looks outstanding case even after fix of bug 710056.

First of all, please rule out "IMAP & Repair Folder" case by reading bug 710056 comment #1 well and reading Bug 550286 what is pointed by that comment since initial open of that bug.
This test extension, named WinBackMyTrash o.0.6, has 2 customized ToolBar buttons. Button1/"Thread column setting" is for this bug & bug 813539.

How to use.
1. Add button1 & button2(i icon) to Menuw Bar(or ordinal ToolBar).
   Open Error Console.
2. After column setting change of a mail folder by you
   or without column setting change,
   Just before restart of Tb by any event,
   (normal termiation/restart, restart by upgarade of Tb/addon)
   Select relevant mail folder at flder pane,
   Select buton1/"Thread column setting",
   Copy Error Console log to Text Editor, Save as file.
   Confirm that column setting data is correct(no mismatch with actual display) 
   Note: This is dump data of JavaScript object. i.e. Data held in memory.
3. Just before restart of Tb, keep backup of .msf file of the relevant folder.
   Is column setting data held in .msf correct? Or obsolete one?
   Note-1: column setting data is not physically written to .msf file
           until event such as folder close occurs.
           So, if the relevant mail folder is opened at messsenger window,
           latest column setting data is not held in .msf at this stage.

After it,
4. If you see your problem on mail folder after restart of Tb, check column setting data in .msf file, shown column setting data by addon, actual column display staus.
Is column setting after restart same as one in .msf at step 3?
Or different one such as internal default column set?

For checking SpecialUse flag of Inbox.
Select your prooblematic Inbox at folder pane, select button2/Selected mail/Folder info, copy Error Console log to Text Editor.
SpecialUse flag obtained via msgFolder.isSpecialFolder(flag-type) is shown to Error Console. But if Inbox(Inbox flag is set), SentMail flag state is not returned(always false) by isSpecialFolder(SentMail).
Let me know "flags" property value of msgFolder object for your Inbox.

By the way, if you want to know about properties/provided function of gFolderDisplay object, select a folder at folder pane, and select button2/Window Object/miscellaneous, copy Error Console log to Text Editor.
This is summary data of gFolderDisplay.getColumnStates() of Inbox, Thread column entry in Inbox.msf, which was obtained by annihilannic@hotmail.com.
Following is copy of mail sent to me.
> I installed the WinBackMyTrash extension, collected the folder and thread column setting information you described,
> saved a copy of Inbox.msf and then used "Help -> Restart with add-ons disabled" to restart Thunderbird. 
> This caused the column settings to be reset (From disappeared, Recipient appeared).
>
> I then collected the same information, which I have attached.
>
> I used "Restart with add-ons disabled" because this problem seems to occur most frequently when TB restarts itself somehow.
> If I just close the programme normally it rarely happens.

Phenomenon is well seen by actual data, without extra explanation.
(0) SentMail bit is Off, Inbox bit is On, in msgFolder.flags
(1) Before restart, (i)  SenderCol:visible=true  / recipientCol:visible=false
(2) After restart,  (ii) SenderCol:visible=false / recipientCol:visible=true
    Data in Inbox.msf.
      data of (i)  is still held in Inbox.msf at same Line=11700.
      data of (ii) is added to Inbox.msf(Line=15707).

(a) Thread column data at Line=11700 dosn't look used, even though it is correctly saved in Inbox.msf.
(b) Upon falling back to default, incident of "This is Inbox", both "MboxName==Inbox" and "Inbox bit in msgFolder.flags == On", looks ignored.
(c) Final fallback seems "default column set of Sent type folder" or "default of default of default of ..." like one.
Confirmin, per Inbox.msf data and gFolderDisplay.getColumnStates() data obtained by pretty simple but special restart of Tb.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> used "Help -> Restart with add-ons disabled" to restart Thunderbird. 
> > This caused the column settings to be reset (From disappeared, Recipient appeared).

I couldn't see column setting change by quick tests of it in Tb 17.0.2.
However, I could see a diffrence between (i) "in ordinal mode, before restart" and (ii) "after Restart with add-ons disabled" : window position/width/height.
(1) in ordinal mode. window-position=XX/YY,width=WW,height=HH.
(2) Restart with add-ons disabled. window-position=xx/yy,width=ww,height=hh
(3) Restart with add-ons disabled again. window-position=xx/yy,width=ww,height=hh
    Same as (2)
(4) Terminate Tb, normal restart of Tb
    => window-position=XX/YY,width=WW,height=HH
    This is same as (1), instead of (2)/(3).
Because xx/yy,ww,hh is far different from XX/YY,WW,HH in my environment fortunately, I could be aware of the difference at a glance while doing "Restart with add-ons disabled". 

I believe above is not applicable to column setting, but incident of "such difference exists" may be relivant to this bug.
FYI.

Writing/getting columnStates to/from DbFolderInfo is done by following.
> Writing
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#434
> 447   _persistColumnStates: function FolderDisplayWidget__persistColumnStates(aState) {
> 451     let dbFolderInfo = msgDatabase.dBFolderInfo;
> 452     dbFolderInfo.setCharProperty(this.PERSISTED_COLUMN_PROPERTY_NAME,
> 453                                  JSON.stringify(aState));
> 454     msgDatabase.Commit(Components.interfaces.nsMsgDBCommitType.kLargeCommit);
> Getting
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#416
> 423   _depersistColumnStatesFromDbFolderInfo:
> 424       function FolderDisplayWidget__depersistColumnStatesFromDBFolderInfo(
> 425         aDbFolderInfo) {
> 426     let columnJsonString =
> 427       aDbFolderInfo.getCharProperty(this.PERSISTED_COLUMN_PROPERTY_NAME);
> 431     return JSON.parse(columnJsonString);

_depersistColumnStatesFromDbFolderInfo(getting columnState from .msf) is called by onLoadingFolder.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#936
> 942   onLoadingFolder: function FolderDisplayWidget_onLoadingFolder(aDbFolderInfo) {
> 943     this._savedColumnStates =
> 944       this._depersistColumnStatesFromDbFolderInfo(aDbFolderInfo);

By onDisplayingFolder, restoring columnStates is donefrom _savedColumnStates.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#955
> 955   onDisplayingFolder: function FolderDisplayWidget_onDisplayingFolder() {
> 961     // makeActive will restore the folder state
> 962     if (!this._savedColumnStates) {
> 963       // get the default for this folder
> 964       this._savedColumnStates = this._getDefaultColumnsForCurrentFolder();
> 965       // and save it so it doesn't wiggle if the inbox/prototype changes
> 966       this._persistColumnStates(this._savedColumnStates);

And, _restoreColumnStates() looks called only when "persisted state" exists.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#1608
> 1608       // Always restore the column state if we have persisted state.  We restore
> 1609       //  state on folder entry, in which case we were probably not inactive.
> 1610       this._restoreColumnStates();
_restoreColumnStates() is defied a follows and done from _savedColumnStates.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#665
> 665   /**
> 666    * Restores the visible columns saved by |_saveColumnStates|.
> 667    */
> 668   _restoreColumnStates: function FolderDisplayWidget__restoreColumnStates() {
> 669     if (this._savedColumnStates) {
> 670       this.setColumnStates(this._savedColumnStates);
> 671       this._savedColumnStates = null;

As seen in dump data of gFolderDisplay, gFolderDisplay._savedColumnStates is null.
>    gFolderDisplay._columnsDirty = false
>    gFolderDisplay._savedColumnStates = null
This means one of next.
(a) onLoadingFolder gets columnStates from .msf,and  set in _savedColumnStates.
    _restoreColumnStates restores columnStates from _savedColumnStates,
    and sets _savedColumnStates=null.
(b) Other.
    onLoadingFolder is skipped, or onLoadingFolder is called too early,
    or onLoadingFolder is interfered, someone cleared _savedColumnStates...
    
Because it looks "pass of (a)" always works normally in ordinal restart, something wrong such as MsgDB open failure, MsgDB contension, Outdated msf condition etc. may happen in "Restart with Add-Ons Disabled".
Folllowing your column setting(visible=true only) 
> (1-A) Before restart of Tb, gFolderDisplay.getColumnStates()  (2-A) After restart of Tb, gFolderDisplay.getColumnStates()
> Thread column setting                                         Thread column setting
>   threadCol              = { visible = true, ordinal = 1 }      threadCol             = { visible = true, ordinal = 1 }
>   attachmentCol          = { visible = true, ordinal = 3 }      attachmentCol         = { visible = true, ordinal = 3 }
>   subjectCol             = { visible = true, ordinal = 11 }     subjectCol            = { visible = true, ordinal = 11 }
>   unreadButtonColHeader  = { visible = true, ordinal = 5 }      unreadButtonColHeader = { visible = true, ordinal = 5 }
>   senderCol = { visible  = true, ordinal = 7 }   <- mismatch->  recipientCol          = { visible = true, ordinal = 9 }
>   dateCol = { visible    = true, ordinal = 15 }                 dateCol               = { visible = true, ordinal = 15 }
>   sizeCol = { visible    = true, ordinal = 17 }                 sizeCol               = { visible = true, ordinal = 17 }
>   accountCol = { visible = true, ordinal = 21 }                 accountCol            = { visible = true, ordinal = 21 }

If "fallback to default column set" like one, I can't imagin reason why accountCol is visible=true after restart.
And, if "fallback" like one, it's based on folder flag, so I can't imagine reason why "Sent type column set" is applied even though Inbox which doesn't have any flag for OutgoingFolder.
  isIncomingFolder == ! isSpecialFolder(SentMail | Drafts | Queue | Templates)
  isOutgoingFolder ==   isSpecialFolder(SentMail | Drafts | Queue | Templates)
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#391
> http://mxr.mozilla.org/comm-central/source/mail/base/modules/dbViewWrapper.js#1371

I guess that old setting saved at somewhere by someone(by Tb, may be by addon) is used after "Restart with Add-Ons Disabled", as window position/width/height is loaded from independent setting or old setting(for example, localstore.rdf if safe-mode, session.json and so on if normal mode).
FYI.
getColumnStates etc. was also defined in messageWindow.js.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/messageWindow.js#131
> 131   // we don't care about columns.
> 132   setColumnStates: function () {},
> 133   getColumnStates: function () { return {}; },
> 134   _depersistColumnStateFromDbFolderInfo: function () { return {}; },
> 135   _getDefaultColumnsForCurrentFolder: function () { return {}; },
> 136   _persistColumnStates: function () {},
> 137   _saveColumnStates: function () {},
> 138   _restoreColumnStates: function() {},
getColumnStates() of Folder Display, which is invoked by FolderDisplayObject.getColumnStates(), is defined in folderDisplay.js.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#615
In folderDisplay.js, these function are invoked via this.getColumnStates().

If getColumnStaus/this.getColumnStates() is invoked with incorrect context or object or "this", it may do nothing instead of raising exception.
This kind of wrong context may occur if "Restart with Add-Ons Disabled", because it's "Disabled" and is never "Uninstalled". i.e. Some changes by installing add-onmay affect on Tb's behaviour even when add-on is disabled.
For example, creates global variable of window.folderDisplay but not correctly initializes if disabled, generates prefs.js entry but can't set propery if disabled.

Can you reproduce your problem with newly created Tb profile? (i.e. no addon except forced addon by Tb such as Test Pilot)
How about with actually no add-on(any forced add on by Tb is also unistalled)?
It appears that the if the Inbox folder is set to show both From and recipient, then both will stay active. It may only be when the Recipient column is turne off that this bug appears. (at least for now). The full bug may reappear later.
(In reply to Hillel Markowitz from comment #18)
> It appears that the if the Inbox folder is set to show both From and recipient, then both will stay active.
> It may only be when the Recipient column is turne off that this bug appears. (at least for now).

> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#396
> 396     // recipient = To. You only care in outgoing folders.
> 397     recipientCol: function (viewWrapper) {
> 398       return viewWrapper.isOutgoingFolder;
http://mxr.mozilla.org/comm-central/source/mail/base/modules/dbViewWrapper.js#1388
> 1388   get isOutgoingFolder() {
> 1389     return this.displayedFolder.isSpecialFolder(this.OUTGOING_FOLDER_FLAGS,
> 1390                                                 true);

It may be;
  Due to some timing related issue,
    msgFolder.isSpecialServer(OUTGOING_FOLDER_FLAGS) returns true for Inbox.
    and !msgFolder.isSpecialServer(OUTGOING_FOLDER_FLAGS) is false.
  If both of SenderCol and RecipientCol is already shown, nothing is changed,
  because there is no need to care about Inbox or Sent.
If so, 1390 true => 1390 false may be a bypass.
  Second parm of isSpecialFolder() might be "default when error"(I'm not sure),
  and "timing issue" may be "msgFolder.isSpecialFolder is defined but
  msgFolder.flags is not correctly set yet or not accessible yet".
  See bug 831664 for issue of "undefined of some incomingServer.<property>". 

By the way, persistColumnStates perhaps comes from <treecol> element.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/messenger.xul#441
> 441                         <treecol id="recipientCol" persist="width" flex="4"
> 442                                  hidden="true" swappedhidden="false"
> http://mxr.mozilla.org/comm-central/source/mail/base/content/SearchDialog.xul#137
> 137             <treecol id="recipientCol" persist="hidden swappedhidden ordinal width" flex="4" 
> 138                      hidden="true" swappedhidden="false"
FYI.
If problem like following is assumed,
  Inbox.msf couldn't be accessed normally upon column setting(load/open of View).
  Inbox.isSpecialServer(OUTGOING_FOLDER_FLAGS) returned true for Inbox.
following is explained.
  Why column setting in .msf is not used(perhaps was not read, was unable to read).
  Why new column setting data is independently added to .msf.
  Why Sent type column is set even though Inbox.
  Why no problem if both SenderCol and RecipientCol is shown.
Some my assumptions were wrong.
Second parameter of isSpecialFolder was "whether check parent folder or not".
> http://mxr.mozilla.org/comm-central/source/mailnews/base/util/nsMsgDBFolder.cpp#4383
This is for "Consider child of Inbox, Sent etc, as Inbox, Sent etc.".
Because top level Inbox of local mail folder in you case, parent is isSever=true folder(==rootFolder, mail directory for the server), and has msgFolder.flags==28(0x1C, 001 1100) like value.
  const nsMsgFolderFlagType Elided          = 0x00000010;
  const nsMsgFolderFlagType Directory       = 0x00000008;
  const nsMsgFolderFlagType Mail            = 0x00000004;
So, if Inbox.isSpecialFolder(OUTGOING_FOLDER_FLAGS,true)==0 occurs, LocalServerDirectory.isSpecialFolder(OUTGOING_FOLDER_FLAGS,false) is executed, and it should return false.

Comparison is done by "if ((mFlags & aFlags) == 0)" where aFlag is OUTGOING_FOLDER_FLAGS and mFlags is Inbox.flags value.
So, I guess phenomenon is "mFlags is not initialized upon flag check and garbage data held in mFlags is used by logical_and operation".
FYI.
Inconsistent thread column is easily seen if multiple tabs, multiple messenger windows are used.
(1) Multiple messenger windows, multiple tabs, open same Mbox at each tab
    Messenger-Window-1 : Tab-1-1(Col-1-1), ..., Tab-1-M(Col-1-M), ...
                     |               |                      |
    Messenger-Window-N : Tab-N-1(Col-N-1), ..., Tab-N-M(Col-N-M), ...
    Because ColumnStates of <treecol> is held for each tab of each window,
    "N*M different ColumnStates for an Mbox" is possible while Tb is running.
(2) Terminate Tb.
    Each Tabs's status of each window is saved to sessions.json,
    but ColumnStates is held in .msf only, and only one active ColumnStates.
    Perhaps, upon close of Window-X, ColumnStates of main tab of Window-X is
    written to .msf, and it's repeatd for Window-1 to Window-N.
    "Finally active ColumnStates in .msf" is perhaps one used by last closed
    window.
(3) Restart Tb.
    ColumnStates is restored from ColumnStates data in .msf file.
    So, ColumnStates after restart may be far different from what user remembers
    at a tab of a window in M*N tabs he opened before termination of Tb.

arthur.gaughan@verizon.net(bug opner) and Hillel Markowitz, please surely rule out such phenomenon from this bug ;-)
Another my wrong guess or assumption.
If ColumnState in Ibox.msf was not read, why AccountCol can be kept after restart and why can be no problem in both SenderCol and RecipentCol case?
Main cause may be "true for Inbox.isSpecialFolder(OUTGOING_FOLDER_FLAGS,true)" only.
(1) ColumnStates is restored from data held in Inbox.msf(msgDatabase)
    by onLoadFolder process, and AccountCol/visible=true is set.
(2) After (1), before (3), something wrong occurs in msgDatabase or msgFolder
    processing due to "Restart with Add-Ons Disabled", and mFlags is garbled.
(3) In onLoadFolder or onLoadView process,
    because Inbox.isSpecialFolder(OUTGOING_FOLDER_FLAGS,true)==true is returned,
    when SendeCol/visible=true, RecipientsCol/visible=false
         changed to SendeCol/visible=false, RecipientsCol/visible=true
    when SendeCol/visible=false, RecipientsCol/visible=true
         nothing is changed, because matches with isSpecialFolder()
    when SendeCol/visible=true, RecipientsCol/visible=true
         nothing is changed, because no need to change for Inbox or Sent
(4) After (3), due to (2), known data about ColumnStates in .msf at (1) is lost,
    then new ColumnStates data at (3) is written at different position
    of Inbox.msf.
Arthur's (the reporter) address is dead. 
And Hillel writes "I have not noticed the problem for some time".

Anyeone else seeing this?
I used to experience this problem quite regularly, but I haven't seen it for a couple of years now.
(In reply to annihilannic from comment #25)
> I used to experience this problem quite regularly, but I haven't seen it for
> a couple of years now.

Thanks for the update. 

Wada, you posted much information here, so please reopen the bug if you think this should not be cclosed
Severity: normal → major
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
See Also: → 813539
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: