Closed Bug 1558572 Opened 5 years ago Closed 5 years ago

Plan for how add-ons should add menu items once the new appmenu lands

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pmorris, Unassigned)

References

Details

After the new appmenu lands in Thunderbird (see bug 1546309), when add-ons try to add items to that menu it most likely will no longer work because the structure has changed. (This also affects Lightning.)

Going forward, make a plan and implement it for where and how addons should add menu items, now that we have the new appmenu.

See comments 18-21 on bug 1546309: https://bugzilla.mozilla.org/show_bug.cgi?id=1546309#c18 for prior discussion.

I think it's worth quoting Philipp Kewisch [:Fallen]'s comment 21 from here: https://bugzilla.mozilla.org/show_bug.cgi?id=1546309#c21


As long as we allow add-ons to do anything we'll be breaking all the add-ons with basically any UI change we do. I don't want to go deep into the merits of extensibility here, that is always a heated discussion.

What I can comment on is how this could fit into a WebExtensions API. The browser.menus API allows for different context areas, one of them is tools_menu. I could imagine having a similar context area for other parts of the menu, as appropriate. We should carefully consider where we allow extensibility because once we support it it will be a long term commitment.

I'd suggest going with #2 ["Like in Firefox, let addons add their own buttons to the toolbar where they can have their own menus"] (which works now via browserAction), and then considering a follow-up if more menu extension points need to be added.

Blocks: 1558599

(In reply to Paul Morris [:pmorris] from comment #1)

I think it's worth quoting Philipp Kewisch [:Fallen]'s comment 21 from here: https://bugzilla.mozilla.org/show_bug.cgi?id=1546309#c21
I'd suggest going with #2 ["Like in Firefox, let addons add their own buttons to the toolbar where they can have their own menus"] (which works now via browserAction), and then considering a follow-up if more menu extension points need to be added.

I agree regarding this approach as it allows us to keep a little bit under control where add-ons can add buttons and menus.
With this approach, we should consider trying to enforce a bit of an "icon consistency" review in order to prevent add-ons adding pixelated PNGs or icons in their toolbar buttons with a completely different style.
We could use the Photo icons guidelines as a started, without being too strict about it. https://style.thunderbird.net/visuals/iconography.html

I'm closing this now since we appear to have settled on letting add-ons add UI elements through the browserAction WebExtension API, which is currently the most future-proof option. As Philipp mentioned, if it turns out that more menu extension points need to be added we can consider additional options at a later point.

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