Closed Bug 1609378 Opened 5 years ago Closed 7 months ago

nsIMsgDBView.addColumnHandler doesn't correctly restore hidden columns

Categories

(Thunderbird :: Add-Ons: Extensions API, defect)

defect

Tracking

(Not tracked)

RESOLVED MOVED

People

(Reporter: me, Unassigned)

References

(Depends on 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

On opening Thunderbird the 'Between' column is displayed in the inbox view. This hasn't been selected to do do so. Changing inboxes and back and it disappears as it should. It also appears sporadically during an open session.

Actual results:

Column displayed that hasn't been set to do so.

Expected results:

Columns shown should be the ones selected.

There's no Between column. Maybe added by an add-on?

According to this support post it is added by the Thunderbird Conversations extension.

Inbox Between Column always turned on in TB 68.4.1

I've had this reported by quite a few people now: https://github.com/protz/thunderbird-conversations/issues/1426

Enigmail have also had this issue but have worked around it: https://sourceforge.net/p/enigmail/bugs/1024/

I can't reproduce it on every folder, but I can reproduce it on some.

STR:

  1. Have Conversations installed
  2. Startup Thunderbird
  3. Hide the "Between" Column
  4. Restart Thunderbird

The "Between" Column is shown again.

From what I can work out so far, the msf file has the correct data - that the between column should be not visible.

However, currently I can't find where the code is that saves and restores the column visible states, but I suspect there is a bug in that code somewhere.

It could be a timing issue - for some folders, the column appears a second or so after startup. So I suspect that things are being loaded, and it gets added too late for the column visible handling code to take affect.

Status: UNCONFIRMED → NEW
Component: Untriaged → Add-Ons: General
Ever confirmed: true
Summary: Incorrect inbox column displaying → nsIMsgDBView.addColumnHandler doesn't correctly restore hidden columns

Note, I'm working on moving Conversations to a WebExtension, so there's not really any point in me trying to save the state here as WebExtensions don't handle uninstall capabilities. Hence this needs to be working.

Just a note that on trunk tree column order things are currently broken - bug 1607432.

So I think this is actually an issue wrt extension startup times and the fact that the folder display manager doesn't handle columns added. I'm currently thinking about proposing a WebExtension API, so I'll see if I can wrap something into that (and also fix it in Conversations).

For now I've gone with the Enigmail solution to see if that helps, but I'm really hoping that we can do the API mentioned in bug 1615801 which would make it so that this is all handled properly.

Depends on: 1615801

Did the change towards delayed background startup change anything for this issue?

Is the switch towards the new tree implementation Geoff is working on (which is at a very early state and can be enabled via mail.useNewMailTabs) going to render this bug invalid?

Flags: needinfo?(standard8)

(In reply to John Bieling (:TbSync) from comment #8)

Did the change towards delayed background startup change anything for this issue?

I can't actually reproduce it myself, only my users can. I did just add an option to disable the column in the add-ons preferences so I'm probably not going to know.

Is the switch towards the new tree implementation Geoff is working on (which is at a very early state and can be enabled via mail.useNewMailTabs) going to render this bug invalid?

Quite possibly, but we should a) check the new tree is compatible to work with WebExtensions, e.g. the existing tree was a pain because there were multiple function calls for the same cell which would end up really expensive across the WebExtension API boundary (and difficult to manage).

One thing would be to do with how the tree saves its column status - I believe the current tree implementation uses the xulstore and my suspicion was about if that had been read or not, or if it had been saved on shutdown. There was no dedicated support for WebExtension provided columns in there, which is what we'll really need.

Flags: needinfo?(standard8)
Component: Add-Ons: General → Add-Ons: Extensions API
Severity: normal → S3

This seems to be fixed with the new custom columns implementation available in Beta. A topicbox post on how to use it will be released tomorrow.

Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.