Open Bug 1375453 Opened 7 years ago Updated 2 years ago

omnibox keywords should be user-overrideable

Categories

(WebExtensions :: Frontend, enhancement, P5)

52 Branch
enhancement

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: horridimpfoobarbaz, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: feature, Whiteboard: [design-decision-approved])

User Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170613225334




Expected results:

Presently, the omnibox API is activated by keywords are set in the extension's manifest.json.

Imagine if there are two extensions on AMO that you wish to use, but which have a keyword collision. You have four options.

One, suck it up and decide which extension you need to use more

Two, go through an activate-deactivate dance when you want to use one rather than the other. This is hardly better than the first option.

Three, ask the developers nicely if they would consider changing keywords. But they presumably have other users to think about--quite possibly including the developers themselves--who will be used to the current keyword. Also, the keyword was probably picked for a reason! The end-game here is a central registry of keywords and 'permission, not forgiveness'.

Four, download one or both, unpack it, edit manifest.json, and load it as a temporary extension in about:debugging. Not reasonable to ask of end-users, and not robust to updates.

None of these are palatable. Instead, I think that it should be possible to configure Firefox to re-bind keywords, probably through about:addons.

Extensions should be able to learn what their keyword is, so that they can display help messages with the correct syntax.
Component: Untriaged → WebExtensions: Frontend
Product: Firefox → Toolkit
Blocks: 1342584
Keywords: feature
Priority: -- → P5
Whiteboard: [design-decision-needed]
Hi bucklereed, this has been added to the agenda for the October 31 WebExtensions APIs triage meeting. Would you be able to join us? 

Here's a few things about the triage to keep in mind: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/Add-ons/Contribute/Triage
* Meeting agenda: https://docs.google.com/document/d/1qqE6fkqr-RNWaFvMpv0Z8O5FLDgQ3AT5eGdbTt7lRGg/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
Flags: needinfo?(amckay)
Everyone thought this was a good idea. Quite a bit of user interface work in about:preferences to make this work. If anyone is taking this on, then you could probably split it down into two (or more parts): the first is allowing the keyword to be changeable in an extension and then the second part it to build out the standard Firefox user interface.
Severity: normal → enhancement
Flags: needinfo?(amckay)
Whiteboard: [design-decision-needed] → [design-decision-approved]
Product: Toolkit → WebExtensions
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.