Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Change keyword for the Omnibox API. #545

Open
newRoland opened this issue Feb 14, 2024 · 12 comments
Open

Proposal: Change keyword for the Omnibox API. #545

newRoland opened this issue Feb 14, 2024 · 12 comments
Labels
enhancement Enhancement or change to an existing feature supportive: chrome Supportive from Chrome supportive: safari Supportive from Safari

Comments

@newRoland
Copy link

newRoland commented Feb 14, 2024

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

@tophf
Copy link

tophf commented Feb 14, 2024

...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.

@xeenon
Copy link
Collaborator

xeenon commented Feb 14, 2024

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

@newRoland
Copy link
Author

newRoland commented Feb 14, 2024

@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.

@bershanskiy
Copy link
Member

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>?")

@newRoland
Copy link
Author

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.

@bershanskiy
Copy link
Member

Would this kind of UI work?
image

@newRoland
Copy link
Author

newRoland commented Feb 15, 2024

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.

@bershanskiy
Copy link
Member

@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?

@newRoland
Copy link
Author

newRoland commented Feb 17, 2024

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

@bershanskiy
Copy link
Member

I filed a Chromium bug to track this feature.

@bershanskiy
Copy link
Member

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.)

@newRoland newRoland changed the title Proposal: Change shortcut for the Omnibox API. Proposal: Change keyword for the Omnibox API. Feb 19, 2024
@xeenon xeenon added enhancement Enhancement or change to an existing feature and removed needs-triage labels Feb 29, 2024
@xeenon xeenon added the supportive: safari Supportive from Safari label Mar 28, 2024
@oliverdunk oliverdunk added the follow-up: chrome Needs a response from a Chrome representative label Mar 28, 2024
@oliverdunk oliverdunk self-assigned this Mar 28, 2024
@oliverdunk
Copy link
Member

Chrome is supportive of this API. It would need to go through security and privacy review, but we don't expect any significant trouble there.

A small thing to consider would be if we should change the keyword key in the manifest to default_keyword, to indicate that it may change.

@oliverdunk oliverdunk added supportive: chrome Supportive from Chrome and removed follow-up: chrome Needs a response from a Chrome representative labels Jul 1, 2024
@oliverdunk oliverdunk removed their assignment Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement or change to an existing feature supportive: chrome Supportive from Chrome supportive: safari Supportive from Safari
Projects
None yet
Development

No branches or pull requests

5 participants