feat(webview): synthesize keyboard and mouse input#41055
Merged
Conversation
Stock WebKit exposes no trusted Input domain, so input must be synthesized with DOM events. Synthetic events do not trigger the browser's default behaviors, so: - keyboard: emulate default text insertion (honoring the selection) on a non-prevented keypress, so press/type actually update inputs. - mouse: fire the full out/leave -> over/enter -> move sequence (mouse and pointer flavors) when the hovered element changes, so hover-driven UI reacts. The page-side dispatch lives in a typed, tsc-checked injected script (packages/injected/src/webview/webViewInput.ts), bundled and installed into every frame via BrowserContext.extendInjectedScript; wvInput drives it through window.__pwWebViewInput. Removes the now-passing input-dependent tests from the webview expectations.
…DOM typing Injecting window.__pwWebViewInput through extendInjectedScript was racy: it re-injects asynchronously after a navigation, so input dispatched immediately after page.goto ran before the dispatcher existed and silently no-op'd. Install it through the page bootstrap script instead, which runs synchronously on every new document before page scripts — no race. Also descend through open shadow roots when resolving the active element, so typing/insertText targets the focused element inside a shadow root rather than the shadow host. Removes the now-passing page-keyboard tests from the webview expectations. The remaining keyboard failures need native default actions that synthetic events cannot trigger on stock WebKit (caret movement, selectAll, clipboard, undo, button activation) or unimplemented features (contentFrame, keyIdentifier).
…ection It fails because elementHandle.contentFrame is unimplemented, not because of generic structural/popup limitations — group it with the other frame-element-and-ownership skips whose comment documents that cause.
keyIdentifier is a legacy WebKit-only property that cannot be supplied via the KeyboardEvent constructor, so synthetic key events reported "". Compute it from the virtual key code (mirroring WebCore's keyIdentifierForWindowsKeyCode) and define it on the event before dispatch. Removes 'should expose keyIdentifier in webkit' from the webview expectations.
The keyboard input fixes make these pass; the only remaining failures in both files are the 'should work with number input' tests, which are it.fail on WebKit upstream and therefore already expected.
The keyboard input fixes also make these pass: - locator-misc-2: should press @smoke, should type, should pressSequentially - page-basic: page.press should work
Typing previously dispatched keydown/keypress and then manually set the value, so the textInput (TextEvent) that real WebKit fires between keypress and input was missing. Dispatch it via initTextEvent and let its default action perform the insertion (which also produces the real beforeinput/input), matching the platform. Enter's text is '\r' but the inserted/textInput data is a newline. Adds a cross-browser test asserting the keydown/keypress/textInput/input/keyup sequence when typing a character.
pavelfeldman
approved these changes
May 29, 2026
Member
pavelfeldman
left a comment
pavelfeldman
left a comment
There was a problem hiding this comment.
Make sure you dispatch events in individual tasks
Drop the WebViewInputInstaller indirection (a leftover from the extendInjectedScript design); the bootstrap now constructs WebViewInput directly with (window, document) and assigns it. Remove architecture-explaining comments, keeping only the browser-specific ones.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Contributor
Test results for "MCP"7233 passed, 1113 skipped Merge workflow run. |
Contributor
Test results for "tests 1"4 flaky43989 passed, 864 skipped Merge workflow run. |
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
2 participants
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.
Summary
Synthesize keyboard and mouse input for the stock WebKit (WebView) backend, which has no trusted Input domain.
window.__pwWebViewInput);wvInputserializes params and drives it.keydown/keypress/textInput, letting thetextInput(TextEvent) default action perform the insertion — matching real WebKit'skeydown → keypress → textInput → inputsequence (Enter'stextis\r, inserted data is a newline). Synthesize the legacy WebKit-onlyKeyboardEvent.keyIdentifier. Descend through shadow roots to find the focused element.extendInjectedScriptso input dispatched immediately after a navigation doesn't race a missing dispatcher.Removes the now-passing keyboard/typing tests from the webview expectations and adds a cross-browser test for the typing event sequence. The remaining keyboard skips need native default actions synthetic events can't trigger on stock WebKit (caret movement, selectAll, clipboard, undo, button activation) or unimplemented features (
contentFrame).