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 (https://addons.mozilla.org/en-US/firefox/addon/to-google-translate/)
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: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=2e5c5542353aa0d9f3c84523a687f3cddbc31c97&full=1
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: https://phabricator.services.mozilla.com/D26067

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.

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

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.

Backed out 2 changesets (bug 1545766, bug 1546633) for causing browser_PanelMultiView_keyboard.js to perma fail

push that caused the backout: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&selectedJob=243835504&revision=041741ce164674137968c39aab0a9c80e84c99db

failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&selectedJob=243835504&searchStr=os%2Cx%2C10.10%2Cshippable%2Copt%2Cmochitests%2Ctest-macosx64-shippable%2Fopt-mochitest-browser-chrome-e10s-2%2Cm%28bc2%29

backout: https://hg.mozilla.org/integration/autoland/rev/47ea779dc66b06fdcc4a247fbe29bf9770cefa8b

https://hg.mozilla.org/mozilla-central/rev/216b689c8984

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.