Fix Tab key unable to reach webview content#321468
Open
meganrogge wants to merge 6 commits into
Open
Conversation
Webview view iframes in the sidebar live in overlay elements at the document root to avoid losing state on reparent. This means they are outside the normal DOM tab order. Keyboard users cannot Tab into webview view content at all. Fix by making the view pane body container tabbable with tabindex=0 and forwarding focus into the webview overlay when it receives focus via Tab. Fixes #314974 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
meganrogge
force-pushed
the
meganrogge/fix-webview-tab-focus
branch
from
e4cdbf8 to
6cb9e42
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes keyboard focus order for webviews rendered via OverlayWebview (whose iframes are mounted at the document root and therefore fall outside the normal DOM tab order). It does so by making the in-flow “anchor/placeholder” elements tabbable and forwarding focus into the overlay webview when they receive focus.
Changes:
- Make
WebviewViewPane’s body container tabbable (tabIndex = 0) and forward focus into the overlay webview on focus. - Make
WebviewEditor’s placeholder element tabbable (tabIndex = 0) and forward focus into the overlay webview on focus. - Add
role="document"on the focus proxy elements to align with existing editor/container patterns in the workbench.
Show a summary per file
| File | Description |
|---|---|
| src/vs/workbench/contrib/webviewView/browser/webviewViewPane.ts | Adds a tabbable focus proxy in the sidebar view body and forwards focus into the overlay webview iframe. |
| src/vs/workbench/contrib/webviewPanel/browser/webviewEditor.ts | Adds a tabbable focus proxy in the editor webview placeholder and forwards focus into the overlay webview iframe. |
Copilot's findings
- Files reviewed: 1/1 changed files
- Comments generated: 0
When focus is forwarded into the webview, try to find and focus the first focusable element (button, link, input, etc.) so keyboard users land directly on interactive content rather than needing an extra Tab. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The editor tabs and toolbar use roving tabindex (tabindex=-1) and are not in the Tab order — they are navigated with arrow keys after F6 brings focus to the editor area. So adding tabindex=0 on the webview editor element does not skip any previously-tabbable controls. Fixes #319907 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Yoyokrazy
previously approved these changes
Jun 15, 2026
The querySelector for the first focusable element inside the webview fires on every focus event, including when notebooks open or cells execute. This steals focus from notebook cell editors and causes notebook/interactive window integration tests to time out. The Tab forwarding from webviewViewPane and webviewEditor already calls webview.focus() → activeFrame.contentWindow.focus(), which is sufficient for keyboard accessibility without the aggressive element targeting. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Yoyokrazy
approved these changes
Jun 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Webview iframes live in overlay elements mounted at the document root (iframes can't be reparented without losing state). This means they are outside the normal DOM tab order of the sidebar and editor area. Keyboard users cannot Tab into webview content at all.
This affects:
Root Cause
OverlayWebviewusesOverlayLayoutElementto position the webview iframe via CSS anchor positioning at the document root. WhilesetParentFlowToestablishes a logical parent relationship, it doesn't affect the browser's Tab order.Fix
Make the webview's anchor element (the placeholder div that remains in the correct DOM position) tabbable with
tabindex=0androle="document". When this element receives focus via Tab, it immediately forwards focus into the webview overlay iframe.webviewViewPane.ts: Addedtabindex=0and focus forwarding on the view pane body containerwebviewEditor.ts: Addedtabindex=0and focus forwarding on the editor elementFixes #314974
Fixes #319907