w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Proposal: Change keyword for the Omnibox API.

newRoland opened this issue · comments

The Omnibox API offers no way to rename the keyword. The user might not like the default keyword, but would still want to use the extension. The user might also want to use more than one extension that use the same keyword.

This capability can be implemented as a developer API, a user-configurable option offered by the browser, or both.

API Proposal

browser.omnibox.setKeyword("foo")  // set to foo. 

browser.omnibox.setKeyword(null)  // set to empty string or null to disable omnibox. 

Browser Option Proposal

As a user configurable setting through the browser. Initially suggested by @tophf

...and the callback/Promise would return an error in case the shortcut is invalid or already occupied.

The browsers could also allow editing it in their extension shortcuts UI because an omnibox shortcut is conceptually a variant of a keyboard shortcut to activate an extension.

Yes, nothing prevents browsers from letting the user edit this in the browser's settings UI.

@tophf @xeenon That's also fine. Currently, I don't think any browser allows doing that.

For Safari and Firefox, I see no options for renaming, disabling a extension's shortcut.

For Chromium, in chrome://settings/searchEngines, it does show an option to "disable" a shortcut, but that just disables the extension.

One advantage to also having an API would be to implement all the extension's settings in one place.

I like the idea of letting user explicitly change the shortcut via browsers' native UI.

On the other hand, the API method like browser.omnibox.setShortcut() seems ripe for abuse by deceptive extensions which could attempt to impersonate other extensions. Perhaps, this API should have a user activation requirement and an explicit acknowledgement by the user (e.g., a permission prompt asking "Do you want to change shortcut of <extension_name> from <old_shortcut> to <new_shortcut>?")

As @tophf suggested, it should return an error if the shortcut is already occupied. With that in place, I don't see enough room for abuse to warrant a permission dialogue.

Would this kind of UI work?
image

That looks great! One little change I would make is replacing "Disable extension" with "Disable keyword". If the user wants, they could disable/delete the extension through Manage.

I didn't consider Disable suggestions before, but that would also be useful.

@newRoland I'm still not entirely sure what exactly you are proposing. Could you please clarify?

The relevant code can be seen here:

The current UI render is:
image

The current entries are:

  • "Manage" - opens extension's management page at chrome://extensions/?id=<extension_id>
  • "Disable" - disables the entire extension

Could you please write down the desired entries and desired behaviors? Preferably, mentioning the exact button label and exact behavior.

Also, the desired UI appearance for the edit thingy. Here are a few considerations (see video for of UI used for other edit menus):

  • Should keyword edit action be initiated by a button in a three-dot-menu or by a "pencil" button?
  • Should the edit UI be an inline input field or an input field on a popover which grabs focus of the current page?

No preference in terms of UI. As long as the user can edit and disable the keyword, that would be great.

I filed a Chromium bug to track this feature.

I just remembered that the manifest entry for the omnibox shortcut is omnibok.keyword (Chrome docs, MDN), so perhaps the method name browser.omnibox.setKeyword() might be more appropriate. (I'm still unsure whether the JS API makes sense.)