Search completion; rework handling when no selection.

This makes the behaviour consistent between custom and non-custom
searches when there is no selection in the vomnibar (omni-mode only).

Approach:
   - When there is no selection in the vomnibar, we *always* send the
     query to to background completer (that is, both for default
     searches and for custom searches) and ask the completer to provide
     only the primary suggestion.  The primary suggestion is just what
     you get if you append the query terms to the search URL (default or
     custom).  We then immediately open the first response.

The round trip for default searches isn't strictly necessary.  However,
this uniform approach disentangles some nasty logic in the vomnibar when
we're trying to handle several cases (default or custom search, with or
without prompted text, with or without any suggestions at all).  The
extra round trip simplifies the logic to such a great extend that it's
worth it.

1 files changed, 1 insertions, 1 deletions

diff --git a/tests/dom_tests/vomnibar_test.coffee b/tests/dom_tests/vomnibar_test.coffee
index e32c050d..380175f3 100644
--- a/tests/dom_tests/vomnibar_test.coffee
+++ b/tests/dom_tests/vomnibar_test.coffee
@@ -14,7 +14,7 @@ context "Keep selection within bounds",
     oldGetCompleter = vomnibarFrame.Vomnibar.getCompleter.bind vomnibarFrame.Vomnibar
     stub vomnibarFrame.Vomnibar, 'getCompleter', (name) =>
       completer = oldGetCompleter name
-      stub completer, 'filter', (query, callback) => callback results: @completions
+      stub completer, 'filter', ({ callback }) => callback results: @completions
       completer
 
     # Shoulda.js doesn't support async tests, so we have to hack around.