Closed Bug 1545766 Opened 4 years ago Closed 4 years ago

Arrow keys cannot be used to control the cursor position in the extensions popup


(Firefox :: Toolbars and Customization, defect, P1)

68 Branch



Firefox 68
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- unaffected
firefox67 --- unaffected
firefox68 --- verified


(Reporter: nayinain, Assigned: Jamie)




(Keywords: regression)


(2 files)

Attached image capture.gif

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

  1. Install the extension (
  2. Open the extension popup and enter some characters in the text box.
  3. Use the arrow keys to control the cursor position.

Actual results:

The cursor position should change

Expected results:

Regression range:

2019-04-19T20:27:19: INFO : Narrowed inbound regression window from [815543d8, 2e5c5542] (3 builds) to [932333a3, 2e5c5542] (2 builds) (~1 steps left)
2019-04-19T20:27:19: DEBUG : Starting merge handling...
2019-04-19T20:27:19: DEBUG : Using url:
2019-04-19T20:27:52: DEBUG : Found commit message:
Bug 1454865: PanelMultiView: When entering a subview using the keyboard, focus the first button after the Back button in the subview. r=Gijs

Differential Revision:

2019-04-19T20:27:52: DEBUG : Did not find a branch, checking all integration branches
2019-04-19T20:27:52: INFO : The bisection is done.
2019-04-19T20:27:52: INFO : Stopped

Sorry for my bad English.

Keywords: regression
Regressed by: 1454865
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Untriaged → Toolbars and Customization
Regressed by: 1477673
No longer regressed by: 1454865
Ever confirmed: true

[Tracking Requested - why for this release]:
User-visible regression in 68.

Priority: -- → P1

Extension panels contain embedded documents; i.e. a <browser> element.
We can't manage keyboard navigation in those, 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.

As part of this, if there are no navigable elements, don't stop the keydown event from propagating.
This is necessary in cases where a view containing a browser element appears, but the browser isn't immediately focused.
In that case, we want to use default tab handling to focus the browser.

Assignee: nobody → jteh
Pushed by
PanelMultiView: Don't override keyboard navigation in embedded documents. r=Gijs
Flags: needinfo?(jteh)
Pushed by
PanelMultiView: Don't override keyboard navigation in embedded documents. r=Gijs
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

Verified the fix under Windows 10 Pro 64-bit and macOS High Sierra 10.13.6 using several Firefox 68 builds, both Nightly and Beta.

Following the provided STR, the issue is no longer reproducible since Nightly 68.0a1 (20190502220333), not occurring on the latest Beta build (68.0b5 - 20190527103257) either.

The issue appears to have been introduced late April, as the issue can be reproduced on Nightly 68.0a1, Build ID 20190427214042 up to 68.0a1, Build ID 20190502095227, including.

Verification of previous versions of Firefox including 60.6.1ESR, Firefox 66 and 67 (Release, Beta and Nightly) revealed that these were unaffected.

You need to log in before you can comment on or make changes to this bug.