Closed Bug 1545742 Opened 2 years ago Closed 2 years ago

the Quantum bar input field intermittently stops handling LEFT/RIGHT/HOME/END key events


(Firefox :: Address Bar, defect, P1)




Firefox 68
68.4 - Apr 29 - May 12
Tracking Status
firefox68 --- fixed


(Reporter: mak, Assigned: adw)




(2 files)

Both me and Dao this morning hit this, but so far we don't have any hints about what may cause it, nor steps to reproduce, I'm filing this anyway to track the problem, and in case someone figures out useful information.
Apparently this started in today's nightly, but we can't be sure because it's intermittent, potentially patches landed yesterday may be on the hook.

If you hit this and can do some investigation through the Debugger, it would be nice, I'll also try to reproduce it.

I forgot the symptoms: basically HOME,END,LEFT,RIGHT stop working, it's not possible to move the cursor for the whole session (likely works in a new window, didn't try)

Summary: the Quantum bar input field intermittently stops handling key events → the Quantum bar input field intermittently stops handling LEFT/RIGHT/HOME/END key events

Sounds like a widget bug to me, TBH.

Attached image capture.gif

I can reproduce that after customizing.

oh yeah, that's a good hint, I can also reproduce after customizing. Thanks for STR.

Duplicate of this bug: 1546869
Assignee: nobody → adw
Iteration: --- → 68.4 - Apr 29 - May 12

Looks like this is related to the input field's CopyCutController. When I comment out this line here, the problem goes away:

Still investigating.

Or rather it's the inputField.controllers.removeControllerAt(0) call in uninit. I'm guessing we end up removing the controller that handles the left/right arrow keys, if that's even a thing?

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:

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!)

Pushed by
Quantumbar: Remove the proper nsIController on uninit and customize start so that left/right arrow and home/end keys work after exiting customize mode. r=mak
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
You need to log in before you can comment on or make changes to this bug.