[bug] Slow and buggy :active effects

[mitchpk]

Describe the bug

In both my own Tauri project and the example project, I am noticing a delay when interacting with buttons with the mouse. Buttons with the default styling sometimes don't immediately change colour when I click down on them or they don't perform their action immediately until I move the mouse after letting go of left click.

This occurs on my laptop and desktop, both of which run Windows. The behaviour is also noticeable with anchor tags and other elements which change their styling or fire an event when the mouse is pressed.

Reproduction

1. Compile and run the "navigation" example project
2. Move mouse over a button and hold down left click
3. Observe that the delay between clicking and the button changing colour is sometimes noticeably long (>100ms)
4. Let go of left click and observe that there is a similar delay before triggering the button's onclick handler

Expected behavior

The button should immediately change its styling when clicking down, and immediately fire an event when letting go.

Platform and versions

Operating System - Windows, version 10.0.19044 X64
Webview2 - 99.0.1150.39
Visual Studio Build Tools:
   - Visual Studio Community 2019

Node.js environment
  Node.js - 16.14.0
  @tauri-apps/cli - 1.0.0-rc.6
  @tauri-apps/api - 1.0.0-rc.2

Global packages
  npm - 8.3.1
  pnpm - Not installed
  yarn - 1.22.17

Rust environment
  rustup - 1.24.3
  rustc - 1.59.0
  cargo - 1.59.0
  toolchain - stable-x86_64-pc-windows-msvc

App directory structure
/node_modules
/src
/src-tauri

App
  tauri - 1.0.0-rc.4
  tauri-build - 1.0.0-rc.4
  tao - 0.6.4
  wry - 0.13.3
  build-type - bundle
  CSP - unset
  distDir - ../build
  devPath - http://localhost:3000/
  framework - React

Stack trace

No response

Additional context

This also appears to happen to the elements within the Webview2 DevTools window.

[KarlitosVII]

Hello,
I'm experiencing the same bug with a Tauri / Dominator app.
It seem to be a bug in the Tauri side (src-tauri) because it appeared when I migrated from beta to rc without recompiling the Web/UI/wasm side.

[amrbashir]

I definitely can reproduce this in wry. Looks like it might be an upstream issue in webview2

[DinCahill]

Hi, I'm using @elibroftw's template and encountered this problem when clicking the buttons.

It only happens as long as the mouse stays completely still while clicking and releasing. Move the mouse, and everything continues immediately as expected.

[juliesaia]

Noticed this too, wanted to add a gif showing the bug:

:
(the background window is chrome using the same Vite project)

[marc2332]

Having the same issue, but it's not specifically related to :active, it's more like a general click capture issue. I made https://github.com/marc2332/wry-slowed-click to show the issue I have with the right click.

[WilliamVenner]

The problem lies in the use of ControlFlow::Wait in the runtime event loop (relevant commit 2e1f207 @lucasfernog). I have experienced this same issue with native UIs that use winit/tao event loop and ControlFlow::Wait. The problem is that the window doesn't get rendered enough in response to input. I don't know whose responsibility that should be, but one crappy solution is to simply use ControlFlow::Poll

--- a/core/tauri-runtime-wry/src/lib.rs
+++ b/core/tauri-runtime-wry/src/lib.rs
@@ -1978,7 +1978,6 @@ impl<T: UserEvent> Runtime<T> for Wry<T> {
     self
       .event_loop
       .run_return(|event, event_loop, control_flow| {
-        *control_flow = ControlFlow::Wait;
         if let Event::MainEventsCleared = &event {
           *control_flow = ControlFlow::Exit;
         }
@@ -2527,10 +2526,6 @@ fn handle_event_loop<T: UserEvent>(
     #[cfg(all(desktop, feature = "system-tray"))]
     system_tray_manager,
   } = context;
-  if *control_flow != ControlFlow::Exit {
-    *control_flow = ControlFlow::Wait;
-  }
-
   match event {
     Event::NewEvents(StartCause::Init) => {
       callback(RunEvent::Ready);

Which "fixes" the issue, but is less performant. I don't think it's really fixing the underlying issue though, which I am yet to discover...

[lucasfernog]

Maybe @wusyong can help you.

[FabianLars]

There were also 100% cpu usage problems with Poll if i remember it correctly.

On the issue itself tho, wasn't this PR tauri-apps/tao#465 created because of this issue? can't remember x)

[WilliamVenner]

Hold on, aren't device events opt-in? You specifically have to register listeners for raw input at least on Windows.

[wusyong]

There were also 100% cpu usage problems with Poll if i remember it correctly.

On the issue itself tho, wasn't this PR tauri-apps/tao#465 created because of this issue? can't remember x)

Yes, this is the one. There are also other place need to refactor a little.

[amrbashir]

Should be fixed now in tauri 1.1