Previously, we sent a command event and a click event.
Normally, the command event executes the action, then the click event closes the menu.
However, in some cases (e.g. the Library button), there is no command event handler and the mousedown event executes the action instead.
Differential Revision: https://phabricator.services.mozilla.com/D29151
Extension panels contain embedded documents; i.e. a <browser> element.
We want users to be able to tab to these and we want them to be focused automatically if a subview is opened from the keyboard, so treat them as tabbable.
However, once an embedded document is focused, we can't manage keyboard navigation inside it, so don't try.
Previously, we tried, which meant keys were overridden even though they didn't do anything, breaking keyboard navigation in extensions altogether.
Differential Revision: https://phabricator.services.mozilla.com/D28442
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
Previously, we sent a command event and a click event.
Normally, the command event executes the action, then the click event closes the menu.
However, in some cases (e.g. the Library button), there is no command event handler and the mousedown event executes the action instead.
Differential Revision: https://phabricator.services.mozilla.com/D29151
Extension panels contain embedded documents; i.e. a <browser> element.
We want users to be able to tab to these and we want them to be focused automatically if a subview is opened from the keyboard, so treat them as tabbable.
However, once an embedded document is focused, we can't manage keyboard navigation inside it, so don't try.
Previously, we tried, which meant keys were overridden even though they didn't do anything, breaking keyboard navigation in extensions altogether.
Differential Revision: https://phabricator.services.mozilla.com/D28442
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
