Closed Bug 1572946 Opened 2 months ago Closed 2 months ago

Browseraction button disappear from toolbar after Thunderbird restart

Categories

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

defect
Not set

Tracking

(thunderbird_esr6868+ fixed, thunderbird69 fixed, thunderbird70 fixed)

RESOLVED FIXED
Thunderbird 70.0
Tracking Status
thunderbird_esr68 68+ fixed
thunderbird69 --- fixed
thunderbird70 --- fixed

People

(Reporter: chris, Assigned: darktrojan)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.94 Safari/537.36 Vivaldi/2.6.1566.40

Steps to reproduce:

Use Thunderbird 68b5 or 69b2

Create a fresh new profile

Install a WebExtension add-on with a browserAction button defined in manifest.json
The installation can be made by manually selecting an .xpi file, of with side-loading (Windows registry).
I did it with my own extension but also addressBooks extension provided in WebExtensions samples:
https://github.com/thundernest/sample-extensions

Check that the button is properly displayed in Thunderbird toolbar and properly respond to clicks.
Then restart Thunderbird

Actual results:

After restart, the browserAction button is briefly displayed in the toolbar and after a few seconds disappear.
The button is then present among all other potential toolbar buttons with "Personalize" toolbar context menu
.
Note that if you reinsert the button manually in the toolbar. It will remain present if you restart Thunderbird several times.

Expected results:

After initial installation, the browserAction button should have remained in the toolbar even after a restart.
It's a problem because if this button is an essential part of your extension to access to some functionalities, the user must find out by himself that it must open "Personalize" toolbar context menu and reinstall the button (if he even knows that such button exists). So the button should remain present after initial installation even after a restart of Thunderbird.

Flags: needinfo?(geoff)

I'm sure I checked this worked when I added it, but I can't find anything to blame for breaking it, so maybe I checked wrong…

Assignee: nobody → geoff
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(geoff)

Sorry for the late report. I only saw it recently because I was mainly using the "Load temporary Add-on" facility. I had shortly tested before usual side-loading but didn't notice the problem (if it ever existed before). I doubled checked that it could not be caused by a side effect, like a specific flag present in my Thunderbird command, or another extension which could be installed by side-loading, but it seemed to be OK. For now, I've switched back to the overlay loader. Despite a couple of initial glitches, and a few adaptations required, it seems to work properly. It greatly helps to manage the transition, as the possibility to enable experimental APIs, even in official releases. Many thanks for all this.

No apology necessary. We wouldn't know there was a problem without your report.

I've changed the code to add the button directly to the persistence store when the extension is first installed (and remove it when uninstalled). The UI then checks the store when asked to add a button.

I've also made a few changes to this flaky mochitest which hopefully will make it more resilient.

Attachment #9084904 - Flags: review?(mkmelin+mozilla)
Attachment #9084904 - Flags: approval-comm-beta?
Comment on attachment 9084904 [details] [diff] [review]
1572946-toolbar-action-persist-1.diff

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

LGTM, r=mkmelin
Attachment #9084904 - Flags: review?(mkmelin+mozilla) → review+
Keywords: checkin-needed
Attachment #9084904 - Flags: approval-comm-beta? → approval-comm-beta+

Actually, this was reported for TB 68 beta. So we should do a 68 uplift?

Flags: needinfo?(geoff)

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/433226218567
Explicitly persist browser/composeAction toolbar position, and clear on uninstall. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 70.0

(In reply to Jorg K (GMT+2) from comment #6)

Actually, this was reported for TB 68 beta. So we should do a 68 uplift?

Yes but I want this in a beta first.

Flags: needinfo?(geoff)
Comment on attachment 9084904 [details] [diff] [review]
1572946-toolbar-action-persist-1.diff

Let's not forget it.
Attachment #9084904 - Flags: approval-comm-esr68?
Attachment #9084904 - Flags: approval-comm-esr68? → approval-comm-esr68+
Comment on attachment 9084904 [details] [diff] [review]
1572946-toolbar-action-persist-1.diff

Doesn't apply. I was going to take it now, but no luck.
Flags: needinfo?(geoff)
Attachment #9084904 - Flags: approval-comm-esr68+
Flags: needinfo?(geoff)
Attachment #9086297 - Flags: review+
Attachment #9086297 - Flags: approval-comm-esr68?
Comment on attachment 9086297 [details] [diff] [review]
1572946-toolbar-action-persist-esr1.diff

Thanks. I see what changed between 68 and 69/70, its the `let icon = ` and `let label = ` stuff. Sorry, when I did the uplifts, this wasn't the only one that didn't apply, so I ran out of patience.
Attachment #9086297 - Flags: approval-comm-esr68? → approval-comm-esr68+
You need to log in before you can comment on or make changes to this bug.