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
Bug 1541929 broke this by bypassing setValueFromResult when autofilling the first result in autofillFirstResult. setValueFromResult sets _resultForCurrentValue, so _resultForCurrentValue is null when _getSelectedValueForClipboard is called. We should call setValueFromResult in autofillFirstResult instead of calling _autofillValue directly.
Differential Revision: https://phabricator.services.mozilla.com/D28560
--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
Applying the attribute early enough allows us to avoid rebinding the urlbar,
plus a few checks to ensure "popup" windows, without a visible toolbar, work
properly.
Differential Revision: https://phabricator.services.mozilla.com/D27253
--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
* 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
This fixes 2 problems causing overrides (with SHIFT/ALT/CTRL) to stick longer than expected:
1. The event bufferer may delay keydown, keyup could then happen before it
2. On some platforms holding a key generates multiple events, so there's no match in number of keydown/keyup
Differential Revision: https://phabricator.services.mozilla.com/D21665
--HG--
extra : moz-landing-system : lando
This also changes the name of 'canceledAuthenticationPromptCounter' to account for the
fact that we no longer count up when the prompt was cancelled, but when it was shown.
Differential Revision: https://phabricator.services.mozilla.com/D21680
--HG--
extra : moz-landing-system : lando
