This adds the stub API for the page data service and some basic docs. The service can be used from
xpcshell tests and the events respond with sane data. As there are no consumers currently the
in-memory cache never clears.
Differential Revision: https://phabricator.services.mozilla.com/D120498
This adds the stub API for the page data service and some basic docs. The service can be used from
xpcshell tests and the events respond with sane data. As there are no consumers currently the
in-memory cache never clears.
Differential Revision: https://phabricator.services.mozilla.com/D120498
This adds the stub API for the page data service and some basic docs. The service can be used from
xpcshell tests and the events respond with sane data. As there are no consumers currently the
in-memory cache never clears.
Differential Revision: https://phabricator.services.mozilla.com/D120498
* Move AddressBar.rst into a new browser/components/urlbar/docs directory
* Break it up into several files, which makes the patch look way bigger than it really is because I used `hg cp` to preserve blame
* Add an Experiments & Extensions file/subsection, to be written later
* Rewrite the intro a little for wording and also to reflect the fact that quantumbar has shipped, and also tweak the wording of some subsection titles
Differential Revision: https://phabricator.services.mozilla.com/D38938
--HG--
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/contact.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/debugging.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/overview.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/telemetry.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/utilities.rst
extra : moz-landing-system : lando
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
