This assumes that the current direction in bug 1522278 is the one we want, which it's looking like it is.
Differential Revision: https://phabricator.services.mozilla.com/D27854
--HG--
extra : moz-landing-system : lando
* In nsAutoCompleteController, the logic that determines whether the new search is a prefix of the old search is only done in HandleText, i.e., on input, not when the value is set programmatically.
* That logic is a lot more complex in nsAutoCompleteController.
* nsAutoCompleteController autofills in one case where quantumbar doesn't: when completing the "placeholder" string before starting a new search and waiting for the async results (thereby preventing flicker).
* Some nsAutoCompleteController state gets reset each time the awesomebar is focused (see calls to attachController() in the autocomplete binding, which sets the controller's input, which calls ResetInternalState()). That state is important in regard to autofill and the placeholder string. If it's not reset, then the autofill of one search will incorrectly affect the autofill of a later search.
Differential Revision: https://phabricator.services.mozilla.com/D22306
--HG--
rename : browser/components/urlbar/tests/browser/browser_UrlbarInput_autofill.js => browser/components/urlbar/tests/browser/browser_autoFill_caretNotAtEnd.js
extra : moz-landing-system : lando
We should replace the context.autofillValue property with a result.autofill property. When the view selects results, it already notifies the input about it by calling input.setValueFromResult(). So we can modify setValueFromResult to check for the presence of result.autofill and thereby get autofill "for free".
result.autofill is an object: { value, selectionStart, selectionEnd }
This is going to help me implement bug 1521702.
One potentially cool thing about doing autofill this way is that any result can now trigger autofill, not only the heuristic result, and do it easily. Of course the user isn't typing when they select a non-heuristic result, so it's probably not fair to call that "autofill", but the result can trigger the selection aspect of autofill. As one example, that might be interesting for search suggestions: Type "foo", key down to the "foobar" suggestion, and the "bar" substring is automatically selected.
Differential Revision: https://phabricator.services.mozilla.com/D18618
--HG--
extra : moz-landing-system : lando
We should replace the context.autofillValue property with a result.autofill property. When the view selects results, it already notifies the input about it by calling input.setValueFromResult(). So we can modify setValueFromResult to check for the presence of result.autofill and thereby get autofill "for free". (The one place where the view doesn't call input.setValueFromResult() when a result is selected is when it selects the preselected result, so this patch adds that.)
result.autofill is an object: { value, selectionStart, selectionEnd }
This is going to help me implement bug 1521702.
One potentially cool thing about doing autofill this way is that any result can now trigger autofill, not only the heuristic result, and do it easily. Of course the user isn't typing when they select a non-heuristic result, so it's probably not fair to call that "autofill", but the result can trigger the selection aspect of autofill. As one example, that might be interesting for search suggestions: Type "foo", key down to the "foobar" suggestion, and the "bar" substring is automatically selected.
Differential Revision: https://phabricator.services.mozilla.com/D18618
--HG--
extra : moz-landing-system : lando
This patch is based on the patch in bug 1520342.
I made the UnifiedComplete provider manually check `context.enableAutofill` before setting `context.autofill`. If we end up with other providers setting `autofill`, they'd have to be careful to check `enableAutofill` too. Maybe it would be better to have a `context.autofill` getter that always returns false when `enableAutofill` is false, or a setter that forces it to be false in that case? Anyway, I opted for a simple approach in this patch.
The patch also rearranges properties so that they're listed in alphabetical order. Not really necessary, but I think it's easier to pick out properties that way, and it's a logical order for adding more properties.
Differential Revision: https://phabricator.services.mozilla.com/D16639
--HG--
extra : moz-landing-system : lando
Creates base classes for providers and muxers. All the classes are exposed
by UrlbarUtils, for 2 reasons:
1. UrlbarProvidersManager on instantiation is importing provider modules, that
may reimport the manager module. Exposing classes from it could cause a
recursive failure.
2. It's nicer if only one of the urlbar modules exports multiple symbols (thus
moving the QueryContext class here too)
Differential Revision: https://phabricator.services.mozilla.com/D14760
--HG--
extra : moz-landing-system : lando
Reporting was already disabled in Bug 1443605.
This keeps the `enabled` getter as a way to detect if it is enabled, in use in BrowserUITelemetry only.
This keeps `addEvent` and related methods, as they are still in use on Android.
Remove suggested and enhanced tiles along with related campaign, frequency-cap, inadjacency, pings, preferences, strings, styles, tests.
MozReview-Commit-ID: FkjaSpSFQHu
--HG--
extra : rebase_source : 1c58ac542180f0abb290639ec1c61b9edf3d0a51
Dão Gottwald
Andreea Pavel
Marco Bonardo
Drew Willcoxon
Bogdan Tara
championshuttler
Boris Zbarsky
Narcis Beleuzu
Michael Kelly
arthur.iakab
Issei Horie
Jan-Erik Rediger
Gijs Kruitbosch
Shane Caraveo
Ed Lee
Alessio Placitelli
Georg Fritzsche
Marina Samuel
Maxim Zhilyaev