1502687 - msgHeaderViewDeck does not store selectedPanel between restarts

Status: UNCONFIRMED

(Thunderbird :: Message Reader UI, defect)

Description

[Joachim Herb]

In my addon CompactHeader I use document.getElementByID("msgHeaderViewDeck").selectedPanel to store the state of the header (expanded/compact) between sessions. This has been working for years up to Thunderbird 60.

First observed with 63.0 beta and still in current trunk, it is not working anymore. 

Steps to reproduce:
- Install CompactHeader beta from http://compactheader.mozdev.org/installation.html)
- Select a message
- Set header mode to compact (SHIFT+H, or symbol in header)
- Exit Thunderbird
- Start Thunderbird newly
- Select a message

Expected result:
- The header of the message is shown compact.

Actual result:
- It is displayed in expanded header mode.

If I start the ESR (60) version of Thunderbird and select compact mode, then close Thunderbird and start a newer version (beta, daily) the first time the header mode is still compact. Only after another restart it is (wrongly) back to expanded header mode.

This is the code not working anymore:

    var deckHeaderView = document.getElementById("msgHeaderViewDeck");

    org_mozdev_compactHeader.debug.log("deckHeaderView.selectedPanel: "
        + deckHeaderView.selectedPanel.id);

    gCoheCollapsedHeaderViewMode =
      deckHeaderView.selectedPanel == document.getElementById('CompactHeader_collapsedHeaderView');

The debug output is always (with beta, trunk):
    deckHeaderView.selectedPanel: expandedHeaderView

So it looks like newer versions of Thunderbird do not store the selectedPanel correctly.

Just closing the main Mail & Newsgroup Windows (open address book, close the mail & newsgroup windows, opening it form the addressbook's tools menu again) works correctly, so the selectedPanel is stored within a session eventhough, the window is closed.

Interestingly, for a separate mail window (Open in New Window) it works as expected: The header state (compact, expanded) is stored correctly even between restarts.

As the same code is used for the Mail & Newsgroup Window as well as for a Mail Window and it worked before, there seems to be a problem with Thunderbird itself.

Comment 1

[Geoff Lankow (:darktrojan)]

The way overlay extensions are loaded has changed, and the panel you're adding to that deck doesn't exist at the point where selectedPanel is restored. So in short, this isn't going to work any more and you'll need to keep track of it yourself.

Comment 2

[Joachim Herb]

(In reply to Geoff Lankow (:darktrojan) from comment #1)
> The way overlay extensions are loaded has changed, and the panel you're
> adding to that deck doesn't exist at the point where selectedPanel is
> restored. So in short, this isn't going to work any more and you'll need to
> keep track of it yourself.

But then I do not understand, why it works, if a current version of Thunderbird is started after an older version. It looks like the problem is storing the information and not restoring it. So I do not understand how the way of overlaying is important here.

Comment 3

[Geoff Lankow (:darktrojan)]

I think it's just coincidence. In fact, I just had another try, and it worked perfectly in 64. So I think what you see might be happening because a new version always loads slower the first time. Some of the things that happen at startup are cached for better performance, but that cache is emptied during an upgrade.

You can check the storage is happening properly by looking at the file xulstore.json in your profile directory.