Webview frozen until mouse moves on Windows

[AmionSky]

Describe the bug
On windows (webview2) after clicks sometimes noting happens until the mouse moves or until ~2 second passes.
The bug was discussed before at tauri-apps/tauri#3691

Steps To Reproduce
cargo run --example hello_world
Open and close the hamburger menu by clicking on it and don't move the mouse
Sometimes it won't open instantly but a second later

Expected behavior
Menu opens/closes instantly always

Platform and Versions (please complete the following information):
OS: Windows 11 Pro 22000.739
Rustc: 1.61.0 (fe5b13d68 2022-05-18)

Would you assign yourself to resolve this bug?

• Yes
• No

Additional context
Last working commit: 3a6eefa
First commit with the bug: 219d20c

Since that commit is a merge and the commits inside of it are tricky to build I'm not certain of this but the possible culprit:
#414 (e056fb2)

From my testing the webview2-rs example does not have this issue

[wusyong]

I found that it won't happen if control flow is poll, and Device Motion Events seem sending like crazy.
Might worth it to replace tao with winit and test it.

Edit: I can confirm it begins from this commit e056fb2
This is exact commit we switch to webview2-com

[wusyong]

Okay, I got some new findings. I tried more approaches like creating the minimum webview, use winit instead, and toggle several options. They all failed. Here is the branch I tested: https://github.com/tauri-apps/wry/tree/wv2-frozon-where-es-mah-suit

What's interested is if I don't call any Windows API in thread_event_target_callback, the freeze is gone. So you either turn to ControlFlow::Poll, or remove the event target callback in tao's implementation.

I'll try to see if I can recreate it in webview2-rs.

[McZazz]

Is this the ControlFlow::Poll in "event_loop.rs" (found in the .cargo\registry\src\githubsomenumber\tao-0.11.2\src\platform_impl\windows folder)? I poked around with it for a bit, but am unable to even hack this file to bits such that it causes a panic, or build failure, or gives any response showing that my changes are propagating to a build.

Is there some step prior to or in addition to doing "cargo tauri build" that I should do to make sure whatever I change in the dependency source code reflects in a build?

I have literally all summer to figure it out :D

[wusyong]

@McZazz Thanks for willing to help!
I have a fix in tauri-apps/tao#427. But I'm still testing if this will bring any subtle change.

[wusyong]

We have lighter PR in tauri-apps/tao#465
But it probably need some more tests.

[AmionSky]

Tried tauri-apps/tao#465 but it does not seem to fix this issue

[wusyong]

@AmionSky Did you try with DeviceEventFilter::Always?

[AmionSky]

@wusyong I have not. Sorry. With the filter set it fixes this

[rgwood]

I've been experiencing this in Tauri for a while. It's a little difficult to understand how wry and the fix in tao relate to Tauri; am I correct in understanding that the fix can't be used in Tauri yet?

[FabianLars]

@rgwood In theory you can tell Cargo to use only wry from git, but iirc wry and tauri changed a bit too much compared to 1.0.5 so you probably need to use tauri from git instead, see https://tauri.app/v1/guides/faq#how-can-i-use-unpublished-tauri-changes

[amrbashir]

this now has landed in tauri, do you still face the same issue?

[AmionSky]

Looks like it's fixed. No longer have the issue in wry or tauri.