1542358 - Allow omnibox.onInputEntered as a user action trigger e.g. for clipboard & browserAction.openPopup()

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement)

Description

[rugk]

Use case

I want to amend the search (omnibar) of Firefox.
When the user submits an entry, instead of opening a tab or so, I want to…

a) open my add-on's popup (looks much nicer and more consistent when the user usually interacts with that, and is often more appropriate when you only have a small visible area/result that does not need a whole page; also prevents taking the user away from the current page)
b) copy something to clipboard.

Actually, I am more interested in a, as for b) I AFAIK could use the "clipboardWrite" permission.

Proposed solution

https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/omnibox/onInputEntered

should be regarded as a user-initiated event (as it 9is, user actively uses keyword and submits entry/chooses suggestion), so https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/browserAction/openPopup works with it.

Ref https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/User_actions (also applies to sidebar as mentioned there, but for this here I guess it makes no difference whether we talk about sidebar or popup.)

Comment 1

[rugk]

Real-world use case/implementation: https://github.com/rugk/awesome-emoji-picker/pull/5

Comment 2

[rugk]

Another thing: It should possibly also grant me the "activeTab" permission…

So in the use case, add one c:
c) Do something with the current page (just as you would when the browser action button is clicked), so I need the "activeTab" permission, too.

Comment 3

[Andrew Swan [:aswan]]

(In reply to rugk from comment #2)

Another thing: It should possibly also grant me the "activeTab" permission…

-1 on that. activeTab gives extensions access to the current tab when the user has expressed a clear intent to interact with the extension. I don't believe that typing something into the location bar is a clear intent to interact with an extension.

Comment 4

[Shane Caraveo (:mixedpuppy)]

(In reply to Andrew Swan [:aswan] from comment #3)

I don't believe that typing something into the location bar is a clear intent to interact with an extension.

Doesn't the omnibox api require an extension-specific prefix? In that case, isn't the user intentionally interacting with the extension?

Comment 5

[Andrew Swan [:aswan]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #4)

Doesn't the omnibox api require an extension-specific prefix? In that case, isn't the user intentionally interacting with the extension?

The user is interacting with some part of the extension, but

1. It is much more subtle than e.g., clicking on an extension's browser action or page action button
2. It is interacting via the location bar which generally means you want to move away from the current page. Giving the extension access to the page you're about to leave in that situation seems strange. Perhaps a clarification about how this would be used would be helpful.

Comment 6

[rugk]

Perhaps a clarification about how this would be used would be helpful.

Okay, so I can of course only describe my case (you can see the code in the PR already linked above). Doing it for all three use cases now (the one you asked is c):

First, note my add-on is an emoji picker.
Generally, the idea is to introduce an emoji search directly in the address bar (including suggestions).

a) permission for openPopup: continue the search to display more emojis in the popup (open popup with search term entered)
b) permission for clipboardWrite: directly copy emoji to clipboard if user selects an emoji suggestion
c) permission for activeTab: (not only) directly copy emoji to clipboard, but also insert into current page/input if user selects an emoji suggestion (so the user does not have to Ctrl+V)

Comment 7

[Mike Conca [:mconca]]

The use case is valid and this isn't a bad idea, but a better way to do this is coming. Firefox is replacing the entire URL bar infrastructure with a new model, codenamed QuantumBar. The new architecture makes the URL bar much more flexible, and should offer better extensibility. While a WebExtension interface into the QuantumBar isn't yet defined, it will likely offer capabilities that allow users to more dynamically interact with the URL bar - like pick an emoji.

Bug 1477942 tracks the QuantumBar progress.

Comment 8

[rugk]

That is great!

That said, for my use case I do not need HTML in the suggestions/address bar, so what I just need are really the appropriate permissions.
And I guess with QuantumBar these also won't go away and we'll have the same discussion then:

• may an add-on open it's popup when completing search?
• may it copy something to clipboard?
• may it interact with the activeTab?

So I guess we would have this issue again, anyway…

Comment 9

[rugk]

The use case is valid and this isn't a bad idea, but a better way to do this is coming. Firefox is replacing the entire URL bar infrastructure with a new model, codenamed QuantumBar. The new architecture makes the URL bar much more flexible, and should offer better extensibility.

This was 3 years ago and I don't know what the status of that idea is (the linked issue is still open so hmm…), so if that thing does not happen, maybe you could reconsider this issue here?

Comment 10

[Mike Conca [:mconca]]

(In reply to rugk from comment #9)

The use case is valid and this isn't a bad idea, but a better way to do this is coming. Firefox is replacing the entire URL bar infrastructure with a new model, codenamed QuantumBar. The new architecture makes the URL bar much more flexible, and should offer better extensibility.

This was 3 years ago and I don't know what the status of that idea is (the linked issue is still open so hmm…), so if that thing does not happen, maybe you could reconsider this issue here?

Passing this along to the current addons product owner.