664535 - Thunderbird forgets the message list header customizations regularly

Status: RESOLVED INCOMPLETE

(Thunderbird :: Mail Window Front End, defect)

Description

[(no longer active)]

This is a problem that I have experienced on trunk (I have never seen this on 3.1).

I do have the Bugmail extension which lets me add custom headers to the message view pane.  I have gotten into the habit of removing a bunch of headers shown by default (like threading, attachment, from, junk status) and add a bunch of others (product, component, user, assignee) and reorder some of them, then after I close Thunderbird while it's been running for a while and reopen it (or close the tab for my bugmail folder and reopen it) the customizations are lost, so I spend 5 minutes again to set things up.

If I close and reopen the folder quickly in an attempt to reproduce this, I don't see the problem.  But leaving Thunderbird running long enough is a sure way of making this happen (I get this every time).

Comment 1

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

That sounds like a pretty unpleasant regression!

Your terminology is not the usual Thunderbird terminology, so let me restate it as I understand it:

- You have an extension that adds custom columns to the thread pane.

- Sometimes, the customizations are lost and reset to the defaults which means that columns you added are no longer present and columns that you removed are present again.

- It's not obvious how to re-create the lossage case.


The most likely explanation is that the custom columns don't exist when the restoration logic happens.  Top-of-my-head possibilities:

a) The way the observer service works changed so that the synchronous notifications that we are creating a new view are now asynchronous so the extension does not get a chance to register its column before we try and restore them

b) Something in the extension changed.  Perhaps it only creates the columns in certain folders now where it used to always create them and b1) it's an asynchronous check that doesn't complete fast enough, or b2) it turns out our column restoration logic only works if the columns already existed in the previous folder.

Comment 2

[(no longer active)]

(In reply to comment #1)
> That sounds like a pretty unpleasant regression!
> 
> Your terminology is not the usual Thunderbird terminology, so let me restate it
> as I understand it:
> 
> - You have an extension that adds custom columns to the thread pane.
> 
> - Sometimes, the customizations are lost and reset to the defaults which means
> that columns you added are no longer present and columns that you removed are
> present again.
> 
> - It's not obvious how to re-create the lossage case.

Yes, these are all correct.

> The most likely explanation is that the custom columns don't exist when the
> restoration logic happens.  Top-of-my-head possibilities:
> 
> a) The way the observer service works changed so that the synchronous
> notifications that we are creating a new view are now asynchronous so the
> extension does not get a chance to register its column before we try and
> restore them

This is plausible, but the customization is _also_ lost for built-in columns (such as From).  If this were the case, those columns should have been restored properly, right?

> b) Something in the extension changed.  Perhaps it only creates the columns in
> certain folders now where it used to always create them and b1) it's an
> asynchronous check that doesn't complete fast enough, or b2) it turns out our
> column restoration logic only works if the columns already existed in the
> previous folder.

The fact that I noticed this as soon as I started to use Thunderbird trunk makes me doubt that this is the case.

Comment 3

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

I assume you're talking about this extension:
https://addons.mozilla.org/en-US/thunderbird/addon/bugzilla-helper/

Preliminary investigation of its source shows it's not doing anything special with its column logic.  The only thing that jumps out is that its XUL overlay has two consecutive splitter nodes, which is curious but likely harmless.

Refreshing my memory of the FolderDisplayWidget column logic also shows that:

- our persistence/restoration is done on the DOM state, so the observer thing should not matter at all.

- if we are screwing up, we are probably throwing an exception that should be visible in the error console, as we are certainly not catching anything.

- silent failure that does not involve a cascading failure about fundamental FolderDisplayWidget invariants would likely have to do with nsMsgDBView.displayedFolder.msgDatabase.dBFolder info betraying us, even though we force an explicit commit on the msgDatabase.


Additional questions:

- Anything in the error console?

- What type of folder is this?  Virtual/unified/saved search folder?

Comment 4

[(no longer active)]

(In reply to comment #3)
> I assume you're talking about this extension:
> https://addons.mozilla.org/en-US/thunderbird/addon/bugzilla-helper/

No.  https://addons.mozilla.org/en-us/thunderbird/addon/bugmail/

> - Anything in the error console?

Nothing from that extension.

> - What type of folder is this?  Virtual/unified/saved search folder?

A regular IMAP folder.

Comment 5

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

(In reply to comment #4)
> No.  https://addons.mozilla.org/en-us/thunderbird/addon/bugmail/

That one doesn't add custom columns to the thread pane as far as I can see in the source.  (It also is not marked as compatible with Thunderbird beyond 3.1, but that doesn't really matter.)  Maybe you have them both installed or you are not talking about the XUL tree widget I am talking about somehow?


In any event, I think that's as far as I can take the analysis other than to note that the "enter IMAP folders quickly" patch doesn't look like it should have affected the column logic.  My last-ditch guess would be folder compaction gone rogue.

Comment 6

[(no longer active)]

(In reply to comment #5)
> (In reply to comment #4)
> > No.  https://addons.mozilla.org/en-us/thunderbird/addon/bugmail/
> 
> That one doesn't add custom columns to the thread pane as far as I can see in
> the source.  (It also is not marked as compatible with Thunderbird beyond 3.1,
> but that doesn't really matter.)  Maybe you have them both installed or you are
> not talking about the XUL tree widget I am talking about somehow?

I do have them both installed, but I may be wrong about which one of them adds the header panes (it's definitely one of them).

Comment 7

[Wayne Mery (:wsmwk)]

Ehsan, if you disable automatic compact, does problem go away, or become less frequent?

Comment 8

[(no longer active)]

I don't know, I have long stopped trying to customize these headers.

Comment 9

[Wayne Mery (:wsmwk)]

=> incomplete based on last comments. If you retest and still see the problem in a recent release please reopen the bug