Repository navigation
[Problem/Bug]: Enabling AllowHostInputProcessing breaks Gamepad API #5406
Description
What happened?
As of WebView2 SDK v1.0.3351.48, AllowHostInputProcessing can be enabled to allow the app process window to handle input. We enabled this as it's important for our purposes (in this case, Steam integration with Construct). However when enabled, the Gamepad API entirely stops working for web content. The documentation does not mention anything about AllowHostInputProcessing affecting gamepad input - only mouse, keyboard, touch etc. - and by default enabling that option does not affect input to the web content, so this appears to be a bug. As Construct is game development software and people often want to play games with gamepads, this is a blocking issue for us.
Importance
Blocking. My app's basic functions are not working due to this issue.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
141.0.3537.99
SDK Version
v1.0.3351.48 and newer
Framework
Win32
Operating System
Windows 11
OS Version
26200.6901
Repro steps
Minimal repro: WebView2GamepadIssue.zip
This is just the Win32_GettingStarted sample updated for the latest SDK, loading this gamepad tester, and with the minimum necessary additions to call controllerOpts4->put_AllowHostInputProcessing(TRUE);. Changing that to FALSE gets gamepad input working again.
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
Activity
AshleyScirra commentedon Nov 17, 2025
Hi folks, any update on this? It's a serious issue for us.
AshleyScirra commentedon Nov 24, 2025
Hi folks, checking in again - is someone from Microsoft able to share a status update on this? It's a serious issue for our tool. We can work around it by disabling AllowHostInputProcessing, but that then breaks the features that depend on that (i.e. the Steam Overlay).
AshleyScirra commentedon Dec 9, 2025
Hi folks, any news on this? It's a serious issue for us and I'd appreciate any update from Microsoft about this.
AshleyScirra commentedon Dec 15, 2025
Hi folks, any update on this? We're keen to hear any news.
BoMichelsenArts commentedon Dec 15, 2025
Ojasvi Das (@ojasvi1450) we await your response.
68kStudios commentedon Dec 16, 2025
Please fix this issue
AshleyScirra commentedon Jan 5, 2026
Ojasvi Das (@ojasvi1450) - this is an urgent issue affecting commercial titles being published to Steam, and has been affecting us for a couple of months now. Could you please prioritize work on this and let us know any updates as they happen? Thank you for any help with this matter.
atultuff commentedon Jan 5, 2026
Hi Folks,
Setting
AllowHostInputProcessing= true shifts the input to be routed to the host app. It is the expected behaviour.You will need to explicitly forward the inputs from the host app to the web content to support gamepad inputs.
This probably is not clearly mentioned in the documentation.
AshleyScirra commentedon Jan 5, 2026
atultuff - I don't believe that is correct. Enabling
AllowHostInputProcessingmeans WebView2 and the host app receive all input. For example the host app can receive keyboard input while the WebView2 is focused. With this view, it is definitely a bug that WebView2 stops receiving gamepad input when that mode is enabled. Perhaps you were thinking of the visual hosting mode where you do need to forward inputs, but this issue reproduces with windowed hosting mode.AshleyScirra commentedon Jan 20, 2026
Hi folks, any update on this? This is a serious issue for us and any news at all would be appreciated.
AshleyScirra commentedon Feb 3, 2026
Hi folks, any update on this? Any news would be appreciated. Given the seriousness of this and the length of time we've been waiting, we are considering doing a significant amount of work to implement a workaround. However we'd rather wait for the fix if it is being actively worked on. It would be frustrating if we invested a lot of time on a workaround only for a fix for this issue to come out soon after, so it is important to us to know what the status of this issue is so we can act accordingly.
xinlanjun commentedon Feb 7, 2026
Please fix this issue，Thank you very much！
castorix commentedon Feb 7, 2026
I tested with Composition (ICoreWebView2Environment10.CreateCoreWebView2CompositionControllerWithOptions) in WinUI 3 C# + P/Invoke on Windows 10 22H2, Edge Runtime 144.0.3719.115, and it seems to work (with https://hardwaretester.com/gamepad and old gamepad "Microsoft® SideWinder® Game Pad USB")
AshleyScirra commentedon Feb 9, 2026
I just tried the original repro again and it still exhibits the issue for me. Perhaps it's to do with windowed mode only, as that's what that repro uses, and it sounds like you tested visual hosting.
castorix commentedon Feb 9, 2026
In fact I also tested with MS sample, being sure that
controllerOpts4->put_AllowHostInputProcessing(TRUE);is called, and it also works (I pressed all gamepad buttons) :
AshleyScirra commentedon Feb 10, 2026
Did you try the repro project I provided? I would guess you still tested a different project that does something different.
castorix commentedon Feb 10, 2026
Yes, it is the Win32_GettingStarted MS sample updated with put_AllowHostInputProcessing (you can see the title "WebView sample")
I checked that put_AllowHostInputProcessing returns S_OK.
AshleyScirra commentedon Feb 10, 2026
I can only assume you've done something different or got confused because the repro project demonstrates the issue for me, and we know from distributing the executable to customers that it affects all of them as well.
68kStudios commentedon Feb 10, 2026
On Construct, I have the issue only with the latest Xbox controller: Playstation 4 and 5 gamepads or older Xbox controllers (like Xbox360) work fine
EDIT: wireless Xbox 360 gamepad, I don't know if it makes any difference
AshleyScirra commentedon Feb 10, 2026
Federico Fanelli (@68kStudios) - I can reproduce the issue as described with an old wired Xbox 360 controller so that does not seem to be entirely true for me. However it does not reproduce for me with an old PS4 controller plugged in via wire - with that I can still get gamepad input even when AllowHostInputProcessing is enabled. That's quite an interesting detail - I suspect Chromium is using different Windows gamepad input APIs for different devices, and only some are broken by enabling AllowHostInputProcessing. Perhaps it's also different depending on whether the controller is wired or wireless, which may explain some inconsistent results here.
With a bit of guesswork and asking ChatGPT (so apply sufficient caution), I would hazard a guess that the raw input API is still working with AllowHostInputProcessing enabled, which supports the PS4 controller via HID, but the more modern Windows.Gaming.Input or XInput APIs are broken by AllowHostInputProcessing. atultuff / Ojasvi Das (@ojasvi1450) - perhaps this detail helps shed some light on the problem and help lead to a fix.
68kStudios commentedon Mar 13, 2026
any update? please, we need a fix
xinlanjun commentedon Apr 29, 2026
Any update? please, we need a fix. thanks!
AshleyScirra commentedon Jun 23, 2026
Hi folks, any update on this? We are having to maintain complicated workaround code until this is fixed.
AshleyScirra commentedon Aug 11, 2026
Hi folks, any update on this? We are keen to remove our workaround and use built-in support for gamepads.
AshleyScirra commentedon Oct 20, 2026
This report is nearly a year old now and we're still very keen for a fix. Does Microsoft have any updates on this?