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
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
Regression
No, this never worked
Last working version (if regression)
No response
The text was updated successfully, but these errors were encountered:
AshleyScirra
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
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.
What happened?
When WebView2 is set to use "Window to visual" hosting mode, the Pointer Lock API no longer works correctly in web content.
This is a potential blocker for Construct migrating from NW.js to WebView2.
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
131.0.2903.70
SDK Version
1.0.2903.40
Framework
Win32
Operating System
Windows 11
OS Version
22631.4460
Repro steps
For a minimal repro, use the Win32_GettingStarted sample, and make the following changes:
CreateCoreWebView2EnvironmentWithOptions()
to set "Window to visual" hosting mode:SetEnvironmentVariable(L"COREWEBVIEW2_FORCED_HOSTING_MODE", L"COREWEBVIEW2_HOSTING_MODE_WINDOW_TO_VISUAL");
webview->Navigate(...)
to: https://downloads.scirra.com/labs/bugs/pointerlocktest.htmlNow run the app and click 'Get pointer lock'.
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
Regression
No, this never worked
Last working version (if regression)
No response
The text was updated successfully, but these errors were encountered: