Bugzilla

I've looked into this some more and here are two options.  (I think the second option is better.)

**Option 1**: Move Calendar menu items into a separate menu accessible via new calendar toolbar button.

This follows how add-ons work in Firefox, using the browserAction WebExtensions API.  However, AFAICT this API only provides a clean slate of an HTML file to work with.  So we would have to "roll our own" menu widget and get it to work and look well-integrated into the app.

Complicating this is the number of Calendar menu items in the appmenu (over 50).  So it would require sub-menus, and you would have to implement a mechanism for that.  Using the appmenu code is appealing, but seems like it would be difficult.  For example, the appmenu code uses XUL and the browserAction works with HTML.

The end result would be a significant change for users.  And since the plan is to eventually move Calendar into TB so it is no longer an add-on, users would have to adapt to this change and then adapt back later.  Also, we would do significant work to move things out of the appmenu only to throw that away and move them back in later.

**Option 2**: Keep the Calendar menu items in the appmenu, via the usual XUL overlay mechanism.

This provides more continuity for users since menu items will remain in the same place as before.  Also the implementation is much more straightforward. We'd just need to add "id" attributes to some <vbox> elements to make it possible to overlay them, and then make the necessary XUL changes.

While it is more future-proof for add-ons to use the browserAction API (as in option 1 above) and we want to encourage that approach, Calendar is an exceptional case since it is bundled with TB, the plan is for it to become part of TB, it is already so fully integrated into the appmenu, etc.

So I plan to move forward with option 2, especially given the benefits of continuity for users and that we need this fixed quickly for TB 68 (which weighs on the side of not hastily making such user facing changes if we can avoid it).

I've looked into this some more and here are two options.  (I think the second option is better.)

**Option 1**: Move Calendar menu items into a separate menu accessible via new calendar toolbar button.

This follows how add-ons work in Firefox, using the browserAction WebExtensions API.  However, AFAICT this API only provides a clean slate of an HTML file to work with.  So we would have to "roll our own" menu widget and get it to work and look well-integrated into the app.

Complicating this is the number of Calendar menu items in the appmenu (over 50).  So it would require sub-menus, and you would have to implement a mechanism for that.  Using the appmenu code is appealing, but seems like it would be difficult.  For example, the appmenu code uses XUL and the browserAction works with HTML.

The end result would be a significant change for users.  And since the plan is to eventually move Calendar into TB so it is no longer an add-on, users would have to adapt to this change and then adapt back later.  Also, we would do significant work to move things out of the appmenu only to throw that away and move them back in later.

**Option 2**: Keep the Calendar menu items in the appmenu, via the usual XUL overlay mechanism.

This provides more continuity for users since menu items will remain in the same place as before.  Also the implementation is much more straightforward. We'd just need to add "id" attributes to some <vbox> elements to make it possible to overlay them, and then make the necessary XUL changes.

While it is more future-proof for add-ons to use the browserAction API (as in option 1 above) and we want to encourage that approach, Calendar is an exceptional case since it is bundled with TB, the plan is for it to become part of TB, it is already so fully integrated into the appmenu, etc.

So I plan to move forward with option 2, especially given the benefits of continuity for users and that we need this fixed quickly for TB 68 (which weighs on the side of not hastily making such user facing changes, as in option one, if we can avoid it).