search

w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
603 stars 56 forks source link

Feature request: grant user gestures (activeTab?) for omnibox events #684

Open ftirelo opened 2 months ago

ftirelo commented 2 months ago

Looking for feedback from the community on this issue.

User gestures are disabled for omnibox events, which prevents an extension from opening the side panel [1]. Those events are only triggered if the user types the keyword in the Omnibox, and browser UI makes it very clear that the extension now has control on what the user is typing, so adding the gesture is safe.

We found this issue while implementing an extension that opens the side panel for a helper after the user typed a query in the keyword mode initiated by the extension, and getting the following error message:

Uncaught (in promise) Error: sidePanel.open() may only be called in response to a user gesture.

I have a WIP Chromium patch to add user gestures to omnibox.OnInputEntered: http://crrev.com/c/5837605

We could optionally add user gestures to the other omnibox events, but user intent may not be as clear for those: OnInputStarted, OnInputChanged, OnInputCancelled, OnDeleteSuggestion.

[1] https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/extensions/api/side_panel/side_panel_api.cc;l=84;drc=3f4203f7dca2f7e804f30cfa783e24f90acd9059

rdcronin commented 2 months ago

I'm supportive of this change from the Chrome side. I think that accepting omnibox input is a fairly intentional action on the part of the user and (at least in Chrome) is clearly attributed to the extension.

I don't think we should add user gestures for the "intermediate" events (OnInputStarted, OnInputChanged, OnInputCancelled, OnDeleteSuggestion), since, as ftirelo mentioned, I think the intentionality here is significantly lower on the part of the user.

Other browser folks, do you have any concerns with adding a user gesture to the onInputEntered event?

hanguokai commented 2 months ago

This Chrome official document says:

The following user gestures enable the "activeTab" permission: ... Accepting a suggestion from the omnibox API

I agree that it is a user gesture, except it's a Chrome bug, not a feature request.

rdcronin commented 2 months ago

Note that Chrome already grants activeTab for onInputEntered (code here). (FWIW, I'm less enthusiastic about that, since I think the association with entering something in the omnibox and running something on the page is lower -- but we don't have any plans to change it, since that would be a breaking change for existing extensions.)

ftirelo commented 2 months ago

The PR that fixes the issue in Chromium has been submitted, and is available in the next Chrome Canary: https://chromium-review.googlesource.com/c/chromium/src/+/5837605

Are there any next step to close this issue here or can it be closed right away?

I'm not used to having those discussions in the context of the Extensions API, so I'd like some guidance from a more experienced stakeholder.

Rob--W commented 2 months ago

Firefox issue tracking this request: https://bugzilla.mozilla.org/show_bug.cgi?id=1542358

Rob--W commented 2 months ago

The PR that fixes the issue in Chromium has been submitted, and is available in the next Chrome Canary: https://chromium-review.googlesource.com/c/chromium/src/+/5837605

I have just updated the label on this issue, from https://github.com/w3c/webextensions/labels/supportive%3A%20chrome to https://github.com/w3c/webextensions/labels/implemented%3A%20chrome.

Are there any next step to close this issue here or can it be closed right away?

In the WECG we often keep issues open for a long time, and use the labels to signal support/implementation status across browsers. One browser implementing a request translates to an updated label, and is not necessarily a trigger for closing an issue.

Rob--W commented 2 months ago

Note: during yesterday's WECG meeting, the question of whether omnibox should grant activeTab came up. Safari expressed that granting user interaction and activeTab is tightly coupled in the implementation.

Chrome's documentation already claims that the activeTab permission is granted: https://developer.chrome.com/docs/extensions/develop/concepts/activeTab#invoking-activeTab

I checked Chrome's implementation, and can confirm that this is the case. It was implemented 12 years ago, in Chrome 21.0.1181.0: https://issues.chromium.org/issues/40616924#comment18 / https://source.chromium.org/chromium/chromium/src/+/33a86dbdc9c3df74c911d581d5cc72fd9b5723f6

So all together, the consensus can be summarized as granting user gestures on omnibox.onInputEntered, as well as activeTab for the currently displayed tab under the address bar.