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
The intent here is that the input/view deal with the handling of clicks/pressing enter, and the controller only deals with opening the required item.
Differential Revision: https://phabricator.services.mozilla.com/D8382
--HG--
extra : moz-landing-system : lando
This picks up naming changes from the provider manager landing, and also makes starting a query be named consistently across the modules.
Differential Revision: https://phabricator.services.mozilla.com/D7297
--HG--
extra : moz-landing-system : lando
This links together the controller with the input and view. It moves the fake results generation to the controller. As a result, there is now an input -> controller -> view round-trip in place.
Also hooks up the input with determining if we're in private browsing mode or not.
Differential Revision: https://phabricator.services.mozilla.com/D6261
--HG--
extra : moz-landing-system : lando
This links together the controller with the input and view. It moves the fake results generation to the controller. As a result, there is now an input -> controller -> view round-trip in place.
Also hooks up the input with determining if we're in private browsing mode or not.
Differential Revision: https://phabricator.services.mozilla.com/D6261
--HG--
extra : moz-landing-system : lando
This creates a basic object with minimal search functionality. It currently uses a dummy ProvidersManager that can be replaced once we get the real one.
There are two test files, the unit one is aiming to test at a unit level - stubbing out the manager, and checking the functionality works correctly.
The second is for checking integration with the providers manager, and it does the right things when linked together. For now, this has just a simple check that uses the dummy ProvidersManager for the case of returning a single result matching the URL.
Depends on D4566
Differential Revision: https://phabricator.services.mozilla.com/D4973
--HG--
extra : moz-landing-system : lando
