Note: keyboard navigation with NVDA 2018 in Chrome on Windows does not suffer from this problem. Voiceover on Mac 10.13.6, however, does have the same issue.

Focus seems to move inconsistently when switching tabs with the shortcut. It might be easiest just to put focus on the tab element when switching tabs.

holla@ Thanks for the issue.

Able to reproduce the issue on Windows 10 and Mac OS 10.13.3 on the reported version 68.0.3440.106 and the latest Canary 70.0.3516.0, but the issue is inconsistent.
Issue is not observed on Ubuntu 14.04.

Unable to provide the bisect information as could observe good and bad behaviors in M-68 (68.0.3440.106).
Hence marking this as Untriaged for further updates from Dev.

Thanks..

I can confirm that keyboard access to the axe extension worked as expected 67.0.3396.99. I did not do extensive testing to confirm whether or not the functionality worked consistently, however.

Further testing keyboard access testing in Chrome Developer Tools version 68.0.3440.106 was very inconsistent - not just navigation, but navigation and tabbing to switch focus based on whether or not I had additional Dev Tools panels such as the console open or not. Sometimes I was able to open various panels, close the panels, and then keyboard access became available. I was unable to establish any consistent pattern to this, however.

One thing I did note in one attempt to cmd + ] over to axe in dev tools was discovered by accidentally pressing cmd + p with the focus on the axe extension tab which displayed a sort of cmd line with instructions to "Type '?' to see available commands:

https://slack-files.com/T03KL259V-FC4L826D7-8bd240dc81

Further exploration of this unexpected functionality didn't get me any closer to keyboard access to the axe extension functionality.

I also found that I was inconsistently able to change the focus in the axe extension via the tab key depending on whether or not I had the console open before I attempted to change the focus:

https://slack-files.com/T03KL259V-FC4LQ0KC1-7d3474f95e

Attempts to recreate this were inconsistent though - I couldn't find a pattern worth reporting.

And, as the OP stated above, once I allowed the 68.0.3440.106 update to complete, I was no longer able to do anything to change focus via the keyboard with no additional AT running such as VoiceOver - also mentioned above.

I hope this further information may be helpful to further Chromium Dev debugging efforts.

Best regards, and thanks for considering.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a0c855085ddbf0e70feb3428e63198c516cc6ff1

commit a0c855085ddbf0e70feb3428e63198c516cc6ff1
Author: Joel Einbinder <einbinder@chromium.org>
Date: Thu Sep 27 19:33:46 2018

DevTools: Focus the newly selected panel with Ctrl+[ and Ctrl+]

Bug: 872438
Change-Id: I72790fccc75bc4ac0bdf457cbb960a53019ab974
Reviewed-on: https://chromium-review.googlesource.com/1182614
Reviewed-by: Erik Luo <luoe@chromium.org>
Commit-Queue: Joel Einbinder <einbinder@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594814}
[modify] https://crrev.com/a0c855085ddbf0e70feb3428e63198c516cc6ff1/third_party/blink/renderer/devtools/front_end/ui/InspectorView.js

Able to reproduce the issue on Windows 10 and Mac OS 10.13.3 on the reported version 68.0.3440.106, but unable to observe the good behavior on the latest M-71(71.0.3564.0) build by following the below steps.

1. Launched Chrome and added the Axe extension.
2. Hit  Ctrl + Shift + i to open the Devtools.
3. Navigated to Axe extension in Devtools by hitting Ctrl + }.
4. Then hit the tab key and could observe that the focus is not in the devtools, but is on the page content.
Attached is the screen cast for reference.

einbinder@ Request you to check and confirm if anything is missed from our end in verifying the issue and help us in verifying the fix on the latest M-71 build.

Thanks.

Deleted: 872438-M71.mp4 756 KB

	872438-M71.mp4 756 KB View Download

Able to reproduce Chrome Version 70.0.3538.77 (Official Build) (64-bit), MacOS Mojave version 10.14.1 for both the "aXe" and "Overrides" dev tools extensions.

Tabbing into both of these extension panels can only be achieved by either tabbing through the entire webpage or tabbing backwards via 'Shift + Tab'. All other Devtools tabs 'tab' appropriately.

It looks to me that this is working fine as far as DevTools is concerned. We call iframe.focus(), which puts the focus inside the extension panel.

However, focusing the iframe seems to leave the focus navigation starting point wherever it was previously, while putting your focus back on the body. This could be considered a separate bug, but its not DevTools specific.

I'm looking into the underlying issue, to see if we can find a better owner.

Meanwhile, as a workaround, I notice that it behaves as expected if devtools is undocked - focus moves into the extension panel content.

Something I should add, is that undocking the devtools doesn't automatically fix it for me. It sounds like that works only intermittently. I should also note that I observed this with the Audits tab in addition to third-party extensions.

With the devtools undocked: if I cycle through the tabs with the `Cmd + }` shortcut and try to reach an extension tab panel with the TAB key, focus cycles back to the first devtools toolbar button for "Select an element". When docked, it goes into the page content like in the video above. In both cases, it should instead go onto the first focusable item in an extension panel, which is what keyboard and screen reader users need. Right now the sequential focus navigation starting point seems to go to the end and it cycles back around to the top of the page or the undocked devtools UI.

If I cycle back and forth through the tabs a few times with the `Cmd + }` and `Cmd + {` keyboard shortcuts, it does seem to fix itself and I can get to the tab panel content as expected. Something about going back and forth seems to make it work properly.

+dcheng for frame expertise

After doing some digging, it seems like the issue may be in WebFrame::Swap(), which is called when an iframe finishes loading (via RenderFrameImpl::DidCommitProvisionalLoad()) and swaps between a provisional frame and the newly created frame.

This causes FocusController::SetFocusedFrame() to be called with null as the provisional frame is swapped out, but focus is never restored to the newly created frame.

Assigning to dcheng and created a minimised manual test case.

Deleted: x-process-iframe-focus.html 880 bytes

x-process-iframe-focus.html 880 bytes View Download

Workaround for the original devtools issue: https://chromium-review.googlesource.com/c/chromium/src/+/1372105/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9209ec0b7148560764fd944879ba689ccfd03846

commit 9209ec0b7148560764fd944879ba689ccfd03846
Author: Alice Boxhall <aboxhall@chromium.org>
Date: Wed Dec 12 02:31:53 2018

[Devtools] Focus wrapper div around iframe in extension views

Bug: 872438
Change-Id: I86931802744baa8d41a4c6ed2b1c89967fc47138
Reviewed-on: https://chromium-review.googlesource.com/c/1372105
Commit-Queue: Alice Boxhall <aboxhall@chromium.org>
Reviewed-by: Joel Einbinder <einbinder@chromium.org>
Cr-Commit-Position: refs/heads/master@{#615791}
[modify] https://crrev.com/9209ec0b7148560764fd944879ba689ccfd03846/third_party/blink/renderer/devtools/front_end/extensions/ExtensionView.js

Able to reproduce this issue on Windows 10 and Mac OS 10.13.6 on the reported version 68.0.3440.106 and the issue is fixed on the latest M-73 build 73.0.3639.0 as per comment #10.

1. Launched Chrome and added the Axe extension.
2. Hit  Ctrl + Shift + i to open the Devtools.
3. Navigated to Axe extension in Devtools by hitting Ctrl + }.
4. Then hit the tab key and could observe that the focus is in the devtools.
Attached is the screen cast for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

//attaching screen cast for comment #19

Deleted: 872438-M73.mp4 1.1 MB

	872438-M73.mp4 1.1 MB View Download