1244789 - Support richer user interactions in the chrome.browserAction API

Status: RESOLVED WORKSFORME

(WebExtensions :: Frontend, enhancement, P5)

Description

[Giorgio Maone [:ma1]]

People trying to port their existing Firefox add-ons to the WebExtensions API are surprised at how limiting the chrome.browserAction UX is, especially if compared with XUL toolbar buttons. Specifically, browserAction just supports either an onClick callback or a HTML popup, and it doesn't allow the listener to discriminate among mouse buttons/modifiers, for instance to choose either to perform an action or show a popup from the same button. As an aside, in XUL add-ons we also support "hybrid" toolbar buttons which have both a default left-click action and a little arrow icon which you click to show the popup (see https://bugzilla.mozilla.org/show_bug.cgi?id=1166434#c11 )

These limitations are exacerbated by the (probably wise) restriction we copied from Chrome which allows each extension to create only one browserAction or pageAction. 

I wouldn't advocate supporting multiple browserActions buttons or the arrow thing, but I believe we should at least support multiple interactions on the same browserAction instance by exposing secondary mouse buttons and keyboard modifiers (maybe a wrapper on the MouseEvent itself which doesn't leak DOM objects) to the onClick listener (of course I'll leave to our UX experts the final call on details).

Comment 1

[Kris Maglione [:kmag]]

The behavior on right click is intentional, given the current UI guidelines that require all toolbar buttons to have a standard menu. The plan for the moment is to add extra items to browserAction menus to perform actions on the add-on, such as open its options page.

Adding support for menu-button buttons would definitely be nice, though.

(Incidentally, Chrome allows add-ons to have one page action, or one browser action, but not both. We allow both a page action and a browser action.)

Comment 2

[:shell escalante]

it seems Google Translator for Firefox needs this.  based on comment 1, is this something we need UX or do we already have the clear path and it's just determining the priority against other work?

Comment 3

[Blake Winton (:bwinton) (:☕️)]

What does Google Translator for Firefox think they need exactly?  In general, I don't think "We could do this in our existing Firefox add-on" to be particularly compelling, since down that road lies XPCOM and XUL overlay support.  ;)  But if we could find out a little more about what they're trying to do, perhaps there's another, better way for them to do it, or a more restricted bit of functionality we can offer to get them to a similar place.

(Reading the linked bug, it sounds like they would be happy with the menu-button button solution, which I think we can implement without any (visual) UX.  We'ld still need to figure out what the API for that looked like, which means that it's not going to be compatible with Chrome's API, so maybe shouldn't block V1?)

Comment 4

[nobzol]

Hi, I'm Zoli, developer of Google Translator for Firefox add-on. This issue came up when I was trying to migrate the add-on to WebExtensions. The goal is to create a split menu which is currently used not just by me, but Greasemonkey, Firebug and maybe a lot of other add-ons, too.
What do we use it for? To distinguish a primary action (main button) from secondary options (popup):
* Google Translator for Firefox: instant translation / other options (different translation modes, open options)
* Greasemonkey: enable-disable greasemonkey / other options (edit scripts, new script, open options, status report)
* Firebug: activate firebug instantly / other options (UI position, clear console, etc.)

I don't know how these two other add-ons handled this (or they don't use WebExtensions?).

I think a workaround is to give up on this split button, and either put the primary action on the browserAction-popup too which means more clicks to the user, or keep only the primary action on the button (so no popup) which means the user can open Options only in a much more difficult way.

I appreciate any advice, thanks, Zoli.

Comment 5

[:shell escalante]

follow up on in triage based on Zoli's comment 4.  Look at potential of implementing just a subset of chrome.browserAction UX for menu to unblock (Blake's comment 3).

Comment 6

[:shell escalante]

putting high -

Comment 7

[:shell escalante]

triage team - see comment 1.  removed triage flag.  blocking google translator for firefox

Comment 8

[:shell escalante]

not blocking for 51 - but potentially for 52

Comment 9

[Rob Wu [:robwu]]

bug 1405031 and bug 1469148 added support for specific modifier keys and mouse button (middle-mouse, not right-click because the latter is intentionally not overridable).

That should have addressed the requests from this bug.