Given the result span problem described in bug 1699211 and bug 1699607,
currently there's no way for quick suggest to accurately specify the last index
as its suggested index.
Differential Revision: https://phabricator.services.mozilla.com/D109571
Summary of major changes:
* Bookmarks, history, and tabs restriction chars now enter search mode. I added
a method to UrlbarProviderHeuristicFallback to return a result with a keyword
when one of these is used.
* This fixes other bugs like recognizing aliases that are entered at the
beginning of non-empty search strings, and not quasi-re-entering search mode
when search mode is already entered and you type another alias.
* The heuristic now determines whether we enter search mode, similar to how it
also determines whether we autofill. When the heuristic has a keyword but no
keyword offer, and the keyword is one of the recognized search mode keywords,
then we enter search mode, cancel the current query, and start a new query
with the remainder of the search string after the keyword.
* I slightly changed how we detect an alias, but only when update2 is
enabled. Now, an alias must be followed by a space; otherwise, the alias is
not recognized and instead just remains part of the seach string. Because if
we don't do that, then you end up in a strange situation after typing an alias
but before pressing space: The heuristic says "Search with <engine with the
alias>", but we haven't entered search mode yet because you haven't typed a
space yet. This is true for both @aliaes and non-@aliases.
* A consequence of the previous point is that we can still autofill @aliases
with a trailing space, which IMO is important. Then, once the user types any
char (space or not), we immediately enter search mode with the query being
whatever char they typed. This is less important after bug 1658605 landed, but
it's still good to have.
* Previously, `UrlbarView.onQueryResults` called UrlbarInput in order to
autofill after the first result is received. This is circuitous becaue the
input already has an `onFirstResult` method, which I now use to enter search
mode when appropriate. So I moved the autofill call from UrlbarView to
`UrlbarInput.onFirstResult`.
* As I mentioned, I improved some test framework and simplified some related
product (non-test) code. For example:
* I removed `UrlbarUtils.KEYWORD_OFFER.NONE` in favor of just leaving
`keywordOffer` as `undefined`.
* `tailOffsetIndex` can now be `undefined` if it's not relevant.
* I removed empty-string `icon` properties from payloads in favor of
`undefined`.
* In tests, I ignore `undefined` but present properties in payloads so they
don't count when comparing payloads with `deepEqual`.
* We weren't previously comparing `result.source` and `result.type` in
xpcshell tests, and that's important IMO, so I added checks for those and
updated tests.
* `isSearchHistory` is redundant, so I removed it. For form history, we
should be checking `result.source == HISTORY` and `result.type == SEARCH`.
* A bunch of tests needed to be updated for this new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D87944
* Replace PlacesSearchAutocompleteProvider with UrlbarSearchUtils.
* Move the module from toolkit to browser. The only consumers of
PlacesSearchAutocompleteProvider are urlbar and UnifiedComplete.
* I'd like to add functions to UrlbarUtils instead, but
PlacesSearchAutocompleteProvider adds itself as an observer for search
engine changes, and it keeps some state so that alias lookups are O(1). It
has an init function to set that up. That's not quite as easy to do if I
just added some functions to UrlbarUtils, and I think that O(1) lookups of
aliases are worth keeping (vs. O(number of installed engines)), so I kept a
separate module, now called UrlbarSearchUtils.
* Init the search service (via UrlbarSearchUtils) from
UrlbarProvidersManager.startQuery so that every module involved in querying
doesn't need to do it.
* Remove PlacesSearchAutocompleteProvider.currentEngine. Previous consumers can
simply use Services.search directly now that the service is initialized early
(see previous point).
* Remove PlacesSearchAutocompleteProvider.parseSubmissionURL. Here again
consumers can use Services.search directly.
Differential Revision: https://phabricator.services.mozilla.com/D79244
Replace `isRestricting` with `getPriority` -- i.e., replace the binary restricting system with a general priority system. Instead of choosing restricting providers, the providers manager chooses the highest-priority providers.
Differential Revision: https://phabricator.services.mozilla.com/D60093
--HG--
extra : moz-landing-system : lando
Replace `isRestricting` with `getPriority` -- i.e., replace the binary restricting system with a general priority system. Instead of choosing restricting providers, the providers manager chooses the highest-priority providers.
Differential Revision: https://phabricator.services.mozilla.com/D60093
--HG--
extra : moz-landing-system : lando
This API is no longer needed, seeing as the Top Sites experiment is over. Dao suggested in bug 1605958 comment 1 that it be removed.
Differential Revision: https://phabricator.services.mozilla.com/D58375
--HG--
extra : moz-landing-system : lando
Rename acceptableSources to just sources, merge it with the existing sources property.
Differential Revision: https://phabricator.services.mozilla.com/D55082
--HG--
extra : moz-landing-system : lando
Adds a `browser.urlbar.onEngagement` event. Listeners are passed the current engagement state: start, engagement, abandonment, or discard. The extension could use this to record its own parallel telemetry (scalars, event telemetry, etc.) per engagement.
Differential Revision: https://phabricator.services.mozilla.com/D53897
--HG--
extra : moz-landing-system : lando
Split the SEARCH source into SEARCH_NETWORK or SEARCH_LOCAL to distinguish
search results coming from a remote source, from those generated locally.
browser.urlbar.suggest.searches will only affect SEARCH_NETWORK results.
Differential Revision: https://phabricator.services.mozilla.com/D49172
--HG--
extra : moz-landing-system : lando
Add "tip" to the ResultType enum and UrlbarProviderExtension.RESULT_TYPES, corresponding to the new TIP type. Update the existing test.
Differential Revision: https://phabricator.services.mozilla.com/D46248
--HG--
extra : moz-landing-system : lando
`UrlbarResult` objects for search results have a `payload.engine` property, the name of the engine, but extensions won't always know the name Firefox uses internally or even any name at all. For example, the top sites API returns search results with aliases but not names. We should let extensions specify engine URLs and aliases, and we can use them to look up the engine name.
The UrlbarResult.jsm change is unrelated but fixes a minor annoyance I found while working on the top-sites extension. My background script returns results with `isKeywordOffer: true`, but that causes an error in `UrlbarResult.payloadAndSimpleHighlights` because it converts string values to arrays and then expects non-string values to be arrays. Instead, it should be converting non-array values to arrays.
Differential Revision: https://phabricator.services.mozilla.com/D39800
--HG--
extra : moz-landing-system : lando
This provides a set of promises that the searchservice resolves once the search engine has been configured
Differential Revision: https://phabricator.services.mozilla.com/D33660
--HG--
extra : moz-landing-system : lando
This provides a set of promises that the searchservice resolves once the search engine has been configured
Differential Revision: https://phabricator.services.mozilla.com/D33660
--HG--
extra : moz-landing-system : lando
This provides a set of promises that the searchservice resolves once the search engine has been configured
Differential Revision: https://phabricator.services.mozilla.com/D33660
--HG--
extra : moz-landing-system : lando
