When UrlbarInput.uninit is called after customize mode ends, uninit calls this.inputField.controllers.removeControllerAt(0), which is supposed to remove the input's CopyCutController inserted in the constructor. But the controller at index 0 at that point is not the CopyCutController. Instead it's some built-in controller that supports these commands (at least these): cmd_charPrevious, cmd_charPrevious, cmd_beginLine, cmd_endLine. (Verified by adding logging to nsXULControllers::GetControllerForCommand.) That's why arrow left/right and home/end don't work after ending customize mode.
The problem is that this.inputField.controllers in the constructor and this.inputField.controllers in uninit (when customize mode ends) are not the same. I wasn't able to track down why, but I'm guessing that the textbox or something in its state is being reset or cloned when customized mode ends or maybe right after it starts. The CopyCutController isn't in the controllers array at all on uninit. (Verified by adding support for cmd_adw and iterating through the controllers array, looking for a controller supporting cmd_adw.)
Note that urlbarBindings.xml has a try-catch around removeController(), I'm guessing for what turns out to be this reason: https://searchfox.org/mozilla-central/rev/7944190ad1668a94223b950a19f1fffe8662d6b8/browser/base/content/urlbarBindings.xml#190
However, CopyCutController *is* in the controllers array when customize mode starts. So I added a new gURLBarHandler.customizeStart method that calls a new UrlbarInput.removeCopyCutController method.
Other things I tried or thought of doing:
Call gURLBarHandler._reset on customize start instead of end. Problem with that is that the UrlbarInput ends up getting immediately recreated because some other parts of the browser access gURLBar at that time. (Of course I replaced the `gURLBar = this.urlbar` assignment in _reset with another lazy getter definition.)
Just don't worry about removing CopyCutController at all. That seems bad because then we'd leak it, unless the controller is removed or the controllers array is emptied at some point by XUL, and I'm not at all certain about that. (Although I guess this is effectively what awesomebar does, given the link above!)
Differential Revision: https://phabricator.services.mozilla.com/D29613
--HG--
extra : moz-landing-system : lando
This test uncovered a couple of problems:
(1) UrlbarController.handleKeyNavigation relies on event.defaultPrevented to tell whether the one-offs handled the key event. That's a problem when combined with deferring the down arrow key.
handleKeyNavigation is called twice in that case. The first time, the event is deferred (so executeAction = false), and handleKeyNavigation calls event.preventDefault. The second time, the event is being replayed, but defaultPrevented is true from the previous call regardless of whether the one-offs actually handled the event.
So handleKeyNavigation always returns early because it thinks the one-offs always handled the event, so it never properly replays down arrow keys.
(2) UrlbarProviderUnifiedComplete's query promise is never resolved when the query is canceled. That's a problem in general of course but I tripped over it in this test because I need to check results after the query is canceled, and the test ended up hanging since UrlbarTestUtils waits for the query to finish in order to get its results.
It's not a problem in UnifiedComplete itself per se because of course awesomebar uses UnifiedComplete too, and it doesn't have this problem. The difference is that nsAutoCompleteController::StopSearch calls input->OnSearchComplete() (via PostSearchCleanup): https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/toolkit/components/autocomplete/nsAutoCompleteController.cpp#1433
Quantumbar's UnifiedComplete provider is missing that behavior, so this patch adds it by resolving its query promise when the query is canceled.
Differential Revision: https://phabricator.services.mozilla.com/D29300
--HG--
extra : moz-landing-system : lando
This test uncovered a couple of problems:
(1) UrlbarController.handleKeyNavigation relies on event.defaultPrevented to tell whether the one-offs handled the key event. That's a problem when combined with deferring the down arrow key.
handleKeyNavigation is called twice in that case. The first time, the event is deferred (so executeAction = false), and handleKeyNavigation calls event.preventDefault. The second time, the event is being replayed, but defaultPrevented is true from the previous call regardless of whether the one-offs actually handled the event.
So handleKeyNavigation always returns early because it thinks the one-offs always handled the event, so it never properly replays down arrow keys.
(2) UrlbarProviderUnifiedComplete's query promise is never resolved when the query is canceled. That's a problem in general of course but I tripped over it in this test because I need to check results after the query is canceled, and the test ended up hanging since UrlbarTestUtils waits for the query to finish in order to get its results.
It's not a problem in UnifiedComplete itself per se because of course awesomebar uses UnifiedComplete too, and it doesn't have this problem. The difference is that nsAutoCompleteController::StopSearch calls input->OnSearchComplete() (via PostSearchCleanup): https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/toolkit/components/autocomplete/nsAutoCompleteController.cpp#1433
Quantumbar's UnifiedComplete provider is missing that behavior, so this patch adds it by resolving its query promise when the query is canceled.
Differential Revision: https://phabricator.services.mozilla.com/D29300
--HG--
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
We need to handle autofilling the first result separately from autofilling results in general (which happens in UrlbarInput.setValueFromResult), so add a new UrlbarInput.autofillFirstResult method. The controller calls it instead of setValueFromResult. I ported the logic from nsAutoCompleteController, as described in the bug.
Other changes are related to the new test for this.
As part of this work, I was interested in learning how awesomebar handles browser_autoFill_typed.js, so I added it to the legacy tests, with a small tweak in the test for awesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D26852
--HG--
extra : moz-landing-system : lando
Fixes the tokenizer to recognize file:/// urls, plus adds a second layer of
protection, so that if URI fixup thinks the typed string may be an url, we don't
fetch suggestions for it.
Differential Revision: https://phabricator.services.mozilla.com/D26282
--HG--
extra : moz-landing-system : lando
The new tokenizer, to make more natural typing restrictions like "?search terms", "search terms?" or "%my tab",
splits out restriction characters if they appear at the beginning or end of the search string. This means
keywords and aliases can't in general begin or end with a restriction character, but we don't have an input
check to prevent those.
For now the tokenizer can't recognize keywords or aliases, because it can't be made asynchronous until the
Quantum Bar is the default implementation, and anyway the complexity must be considered at that point.
The best we can do is to stop splitting out restriction character in the middle of the search string.
This will allow a part of the old interaction like searching for "keyword? something".
This patch also prevents us from splitting a %encoded string, fixing bug 1538715.
Differential Revision: https://phabricator.services.mozilla.com/D24929
--HG--
extra : moz-landing-system : lando
_autofillValueOnInput correctly uses the placeholder string as the autofilled value, but it incorrectly uses _lastSearchString as the current input value. _lastSearchString at that point is -- yes -- the previous search string, not what the user has just typed. So when _autofillValueOnInput sets selectionStart to _lastSesarchString.length, the length is one char less than what it should be.
But why does that mess up only the last char typed and not every char? Because when the first result comes in, we correctly autofill it. It's only when the first result is not an autofill result that the incorrect placeholder autofill sticks around -- e.g., just after you type the last char in an @ alias.
This patch just gets rid of _autofillValueOnInput and inlines the body in _maybeAutofillOnInput.
Differential Revision: https://phabricator.services.mozilla.com/D24551
--HG--
extra : moz-landing-system : lando
We already have browser_autoFill_preserveCase.js, which checks that we preserve case. This patch extends it to check a couple of more things: autofill is restored on up/down, and the user's input is restored when no result is selected.
Differential Revision: https://phabricator.services.mozilla.com/D24273
--HG--
rename : browser/components/urlbar/tests/browser/browser_autoFill_preserveCase.js => browser/components/urlbar/tests/browser/browser_autoFill_preserve.js
extra : moz-landing-system : lando
