At the moment it is not possible to add suggestions to the awesomebar without using `require("chrome")` and XPCOM like so https://github.com/jetpack-labs/awesomebar/blob/master/index.js#L6 It should be possible to add suggestions and support all of the chrome.omnibox.* api https://developer.chrome.com/extensions/omnibox via a modules available to the add-on sdk. The code above has probably rotted, and I don't think it supports all of the chrome.omnibox.* api

FWIW, we have a keywords API: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Using_the_Places_keywords_API But, first of all we should figure out the use-cases, I'm not into copying Chrome without first figuring out how that API is used, why it exists, and how it can be abused.

(In reply to Marco Bonardo [::mak] from comment #1) > FWIW, we have a keywords API: > https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/ > Using_the_Places_keywords_API This api merely lets one interact with the places api, I need to be able to add suggestions to the awesomebar without affecting the places db.

(In reply to Marco Bonardo [::mak] from comment #1) > But, first of all we should figure out the use-cases, I'm not into copying > Chrome without first figuring out how that API is used, why it exists, and > how it can be abused. Well this is the plan over at bug 1161828, I suggested implementing these features on npm as third party modules, but dcamp disapproved that idea and wants to land these sdk apis in m-c instead.

Personally I find very dangerous to let add-ons directly put stuff into the awesomebar. It's one of our best selling points, the frecency algorithm merging entries is complex enough and thus fragile. I'd first like to see how we are presenting this stuff in the UI. Remember here we only have 6 entries, and we already have many providers (search aliases, keywords, history, bookmarks, open tabs, tags and soon search suggestions) fighting for those 6 slots. Adding more fighters won't improve the user experience, it could instead break it. If we have a UI plan and these entries will go to a special part of the awesomebar, then it's very different. This from a desktop point of view, I can't speak for mobile but I guess there is also a space issue there. A UI plan should come first, imo.

We will probably need a awesomebar ui that supports more than 6 entries.

I agree with Marco that we should be careful about adding an API just for the sake of parity without understanding the repercussions. Some questions I have: - What are the use cases for this? - What are the limitations? (if any) I can think of some reasons we might want to do this, but I can also think of a lot of ways this could go wrong.

So, I was reading the API definition and it's a little bit different than just adding suggestions to the list. The scope of the API is to provide custom suggestions when a very specific keyword is typed, for example add-on "cats-finder" could register the keyword "cats". When the user types "cats something" the awesomebar should fetch suggestions for "something" from the "cats-finder" add-on and show them. Technically This should be feasible with the unified complete code (with some changes...) we are aiming to release in Firefox 42. It's indeed not much different than search suggestions. There are still a lot of questions to answer though. 1. As Stephen said there should be some limitation. 2. There are also privacy implications (all keystrokes after the special keyword will go to the add-on, that can send them remotely) 3. it might be surprising if the user is not notified properly that now a specific word is "taken". So there should be some UI to list and manage these keywords somewhere. (note we also need a new UI to manage bookmarks keywords... and would be nice to merge everything with search service keywords). 4. it might reduce the goodness of the awesomebar if the add-on is not good enough, we might restrict it by only providing the last 3 positions in the popup or just append like we do with search suggestions (that means it won't always appear) 5. it might have performance implications, if the add-on is slow or janky when fetching suggestions, the awesomebar will look slow. These should have some sort of answer.

As explained by Marco over email, I think we can address most of the concerns mentioned above by taking advantage of the new awesomebar design to indicate clearly when an extension is active and what suggestions are coming from the extension. However, I have a couple of follow-up topics and questions that I'd appreciate your advice on: 1. Handling unresponsive extensions - The process for obtaining suggestions from the extension is async, so there is a chance the extension will be slow to respond, or may even be completely unresponsive. I think having a timeout would be useful in this case so we can fall back to showing the normal suggestions if an extension is too slow. How long do you think we should wait before we timeout? Do you have any other suggestions? 2. Limiting the number of allowed suggestions - In Chrome, up to 6 suggestions are shown below the navigation bar at any given time. The Omnibox API allows the extension to control all 6 of these if they wish to. If the extension shows any less than that, the remaining suggestions come from Chrome and are shown after the extension's suggestions. In Firefox, we show up to 10 suggestions at any given time. Should we allow the extension to control all 10 of these, or perhaps the first 5 or 6? What are your thoughts on this?

(In reply to Matthew Wein [:K-9, :mattw] from comment #9) > 1. How long do you think we should > wait before we timeout? Do you have any other suggestions? Does the API allow the add-on to return results one by one, or does it only allow to add all results at once? I think in any case we should give up after 500ms, maybe we could show some kind of undetermined progress so we clarify it's the add-on being slow, like an undetermined progress close the addon name in the locationbar? > 2. Should we allow the extension > to control all 10 of these, or perhaps the first 5 or 6? What are your > thoughts on this? I think it's a good idea to limit the number of results, the numbers are TBD. I think 6 is a good number, we should figure out what to provide after those 6 entries, local history entries, search suggestions, both? I honestly think both questions are better answered by UX.

The omnibox API is landed. Bug 1309047 is still open at the time of writing, but is being tracked by another team. For all intensive purposes, omnibox has landed, yay!

Reopening because there's still a few things left to do.