1375855 - omnibox API: allow calling the suggestion callback from onInputChanged multiple times

Status: RESOLVED WONTFIX

(WebExtensions :: Frontend, enhancement, P5)

Description

[bucklereed]

Attachment: background.js

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

Steps to reproduce:

Install the attached WebExtension. Type 'example foo' in the location bar.


Actual results:

The suggestion is 'First' and stays that way. This is Chromium's behaviour as well.


Expected results:

The suggestion would be 'Second'.

WebExtensions might be able to offer some suggestions quickly, while also wanting to retrieve more or better suggestions asynchronously (e.g., if they hit the network or perform heavier computation). But, presently, calling the addSuggestions callback uses it up.

This behaviour would not be inconsistent with the rest of the awesomebar machinery, where different suggestions can pop up after different amounts of delay. I'm not sure if this might introduce problems with, say, the user moving between the selections and then a new batch arrive; how does the awesomebar deal with this sort of thing?

Comment 1

[bucklereed]

Attachment: manifest.json

Comment 2

[Caitlin Neiman [:caitmuenster]]

Hi bucklereed, this has been added to the agenda for the December 19, 2017 WebExtensions APIs triage. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* 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/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1KwfTum8Ow5w4afPAOvShpu_d_MNtahhOIqL3-Em9lLc/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 3

[Mike Conca [:mconca]]

Policy Review Comments (https://wiki.mozilla.org/WebExtensions/policy)

This request does not appear to run counter to any of the WebExtension policies. I do have one concern around (II) - security and privacy.  Could a malicious extension take advantage of this to overwhelm the omnibox, or try to "out-suggest" other extensions?

I also wonder about drawbacks (V) - how closely is the API tied to the Omnibox (Awesomebar) implementation? Does this tie it closer? Are there timing and/or race conditions that could make this difficult to implement/test/support?

Comment 4

[Andy McKay]

Thanks for the bug. There was concern that this seemed a lot of work, especially on the user interface end of things. 

At this point the omnibox API isn't really used that much by developers. We could argue that perhaps lacking an API like this is the reason, but I don't think so. I think with some more ideas and use cases around this it might make more sense. There's probably better things to do on the omnibox API though.