[bug] Window event is only received after user interaction

[moxaj]

Describe the bug

Scenario: I have a transparent, hidden, always-on-top window. The backend sends an event to it, the window makes itself visible, so far so good. After some time, the backend sends another event to the window, but this event isn't received immediately, only after some user interaction with the window (a mouse click in my case suffices). Also, this is not 100% reproducible.

According to the backend logs, the event is sent when it should be, but the frontend only receives the event upon said user interaction (verified with timestamps). Here's how the listener is set up:

React.useEffect(() => {
    const unlisten = window.getCurrent().listen<State>('update', event => {
        // console.log here
        setState(event.payload);
    });

    return () => { unlisten.then(f => f()); };
}, []);

React.useEffect(() => {
    // do something
}, [state]);

And, fwiw, here's how the window makes itself shown:

const currentWindow = window.getCurrent();
await currentWindow.show();
await currentWindow.setFocus();

Reproduction

No response

Expected behavior

No response

Platform and versions

Operating System - Windows, version 10.0.19043 X64
Webview2 - 99.0.1150.30
Visual Studio Build Tools:
   - Visual Studio Build Tools 2019

Node.js environment
  Node.js - 16.13.2
  @tauri-apps/cli - 1.0.0-rc.5 (outdated, latest: 1.0.0-rc.7)
  @tauri-apps/api - 1.0.0-rc.1 (outdated, latest: 1.0.0-rc.2)

Global packages
  npm - 8.5.1
  pnpm - Not installed
  yarn - Not installed

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

App directory structure
/.git
/.github
/build
/installed
/node_modules
/opencv
/public
/src
/src-tauri

App
  tauri - 1.0.0-rc.3
  tauri-build - 1.0.0-rc.3
  tao - 0.6.2
  wry - 0.13.2
  build-type - bundle
  CSP - unset
  distDir - ../build
  devPath - http://localhost:3000/
  framework - React

Stack trace

No response

Additional context

No response

[moxaj]

I think I know why: the first event (after which the window shows itself) was bound to the hotkey alt + 1. But alt is also the default key to navigate the window menu on the top left (my window has no decorations, but I guess there's no way to disable this?). I'll leave it up to the maintainers to decide whether this qualifies as a bug (not receiving events while the alt menu is focused(?))

[probablykasper]

Maybe related to #2543

[alllex]

I have a possibly related problem, but with a regular single window.

My use case is to be able to use keyboard shortcuts after the app has started and the window is opened. However, this does not work until the said user interaction. The only interaction that enables the keyboard handling is the mouse click within the window.

This problem seems to apply to the keyboard events not being propagated into the webview. Because using the regular browser keyboard events does not work, such as pressing Space key to scroll the page down.

[probablykasper]

@alllex I'm aware of that one. Just in case, I'd say open a new issue and link back to this one

[jfaust]

I think I'm running into the same thing - currently only on Linux, but haven't tested MacOS yet.

I have a window that's invisible until a network event comes in - it's supposed to pop up when that happens, show some progress, and then disappear. This is triggered by progress messages sent using emit(). On Windows this works great. On Linux, the Rust side passes the events through, but then they seem to get batched in a way that they aren't received until much later. Unless any user interaction happens with the window, including just a mouseover (only possible if I've forced the window to stay open), in which case everything works great.

[jfaust]

I've done some digging - it looks like when this happens, the main thread is stuck in the gtk event loop:

gtk::main_iteration_do(blocking);

The eval_script() calls that cause events to be emitted rely on sending a WebviewMessage::EvaluateScript message to the event loop, which is just stuck here not updating - I assume blocking here is causing it to wait for an event from the windowing system.

Edit: Reported to Tao

[jfaust]

Just noticing that the original bug is on Windows, so different from my issue - I haven't experienced the issue there, so haven't investigated, but the root cause could be similar.