You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Problem/Bug]: Gamepad and Pointer Lock APIs not working in visual or "Window to visual" hosting modes #4968
Observed result: the mouse cursor remains visible, and the page does not update with any more pointermove events. Further, the notification saying "to show your cursor, press Esc" appears offset, sometimes outside the window (ideally we would hide this notification as it's not applicable to desktop software - see #4960). Further, after pressing Esc pointer events don't seem to restart again, leaving the app in a stuck state.
Expected result: pointer lock to work normally as it does in a web browser, or in the standard windowed hosting mode. Comment out the line added in step 1 to use windowed hosting mode, and you'll see it works correctly.
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
changed the title [-][Problem/Bug]: Pointer Lock API does not work in "Window to visual" hosting mode[/-][+][Problem/Bug]: Gamepad and Pointer Lock APIs not working in "Window to visual" hosting mode[/+]on Dec 4, 2024
Further testing also indicates that the Gamepad API does not work in this mode either - change the URL to https://hardwaretester.com/gamepad to test that. This is a blocker for web gaming content.
We're trying to use the "Window to visual" hosting mode for better compatibility with the Steam Overlay, as "Windowed" mode doesn't work, and there still doesn't appear to be support for rendering to texture to work around that (#20, #547), so we're trying different WebView2 hosting modes. Regardless, these APIs should work in "Window to visual" mode, as the documentation says it should basically work the same as windowed mode without any API differences.
changed the title [-][Problem/Bug]: Gamepad and Pointer Lock APIs not working in "Window to visual" hosting mode[/-][+][Problem/Bug]: Gamepad and Pointer Lock APIs not working in visual or "Window to visual" hosting modes[/+]on Jun 30, 2025
It looks like this also affects the "visual" composition mode. The WebView2SampleWinComp sample off GitHub also reproduces the issue of no gamepad input when pointed to https://hardwaretester.com/gamepad. For us this is a blocker for using either visual or window-to-visual hosting modes.
Positioned input like mouse and touch input needs to be forwarded to the webview for visual hosting mode as the app may have to transform the input positions - but gamepad input isn't positioned. So shouldn't gamepad input just work regardless of the hosting mode?
We also need pointer lock to work in visual hosting mode, but that at least is potentially more feasible for us to work around from the containing application.
This report is coming up to two years old and it's still important to us to have gamepad input working in visual hosting mode. Is there any update from Microsoft on this?
Activity
[-][Problem/Bug]: Pointer Lock API does not work in "Window to visual" hosting mode[/-][+][Problem/Bug]: Gamepad and Pointer Lock APIs not working in "Window to visual" hosting mode[/+]AshleyScirra commentedon Dec 4, 2024
Further testing also indicates that the Gamepad API does not work in this mode either - change the URL to https://hardwaretester.com/gamepad to test that. This is a blocker for web gaming content.
We're trying to use the "Window to visual" hosting mode for better compatibility with the Steam Overlay, as "Windowed" mode doesn't work, and there still doesn't appear to be support for rendering to texture to work around that (#20, #547), so we're trying different WebView2 hosting modes. Regardless, these APIs should work in "Window to visual" mode, as the documentation says it should basically work the same as windowed mode without any API differences.
[-][Problem/Bug]: Gamepad and Pointer Lock APIs not working in "Window to visual" hosting mode[/-][+][Problem/Bug]: Gamepad and Pointer Lock APIs not working in visual or "Window to visual" hosting modes[/+]AshleyScirra commentedon Jun 30, 2025
It looks like this also affects the "visual" composition mode. The WebView2SampleWinComp sample off GitHub also reproduces the issue of no gamepad input when pointed to https://hardwaretester.com/gamepad. For us this is a blocker for using either visual or window-to-visual hosting modes.
Positioned input like mouse and touch input needs to be forwarded to the webview for visual hosting mode as the app may have to transform the input positions - but gamepad input isn't positioned. So shouldn't gamepad input just work regardless of the hosting mode?
We also need pointer lock to work in visual hosting mode, but that at least is potentially more feasible for us to work around from the containing application.
bradp0721 commentedon Jun 30, 2025
Siv Souvam (MSFT) (@sivMSFT) can you find someone to help with this GitHub issue, since I'm no longer on the WebView2 team?
Everade commentedon Jan 21, 2026
Siv Souvam (MSFT) (@sivMSFT) Brad Peters (@bradp0721)
Could someone please be assigned to this issue?
It's quite a big deal for game-devs.
AshleyScirra commentedon Aug 11, 2026
Any update on this?
AshleyScirra commentedon Oct 20, 2026
This report is coming up to two years old and it's still important to us to have gamepad input working in visual hosting mode. Is there any update from Microsoft on this?