[bug] On Windows, app hangs when creating a new window in a non-async Tauri command

[dceddia]

Describe the bug

Creating this off the heels of #3883 - I noticed that the app hangs if I do window operations in a non-async Tauri command on Windows. Making the command async fixes the problem.

This is the command that hangs:

#[tauri::command]
pub fn open_activation_window(app: tauri::AppHandle) {
    if let Some(window) = app.get_window(ACTIVATION_WINDOW_LABEL) {
        let _ = window.set_focus();
        let _ = window.center();
    } else {
        let window = tauri::window::WindowBuilder::new(
            &app,
            ACTIVATION_WINDOW_LABEL,
            tauri::WindowUrl::App("activation.html".into()),
        )
        .title("Activate Recut")
        .center()
        .focus()
        .inner_size(500.0, 300.0)
        .resizable(false)
        .build()
        .map_err(|e| e.to_string())?;

        // hide the menu
        let _ = window.menu_handle().toggle();
    }
}

This version of it works:

#[tauri::command]
pub async fn open_activation_window(app: tauri::AppHandle) -> Result<(), String> {
    if let Some(window) = app.get_window(ACTIVATION_WINDOW_LABEL) {
        let _ = window.set_focus();
        let _ = window.center();
    } else {
        let window = tauri::window::WindowBuilder::new(
            &app,
            ACTIVATION_WINDOW_LABEL,
            tauri::WindowUrl::App("activation.html".into()),
        )
        .title("Activate Recut")
        .center()
        .focus()
        .inner_size(500.0, 300.0)
        .resizable(false)
        .build()
        .map_err(|e| e.to_string())?;

        // hide the menu
        let _ = window.menu_handle().toggle();
    }

    Ok(())
}

Reproduction

• Create a Tauri app that includes that includes the non-async open_activation_window command.
• Invoke that command from JS

Expected behavior

It should open the window. And according to Lucas, it should be able to do this on the main thread.

Platform and versions

Environment
  › OS: Windows 10.0.19044 X64
  › Webview2: 101.0.1210.39
  › MSVC:
      - Visual Studio Build Tools 2019
      - Visual Studio Community 2019
  › Node.js: 16.9.0
  › npm: 7.22.0
  › pnpm: Not installed!
  › yarn: 1.22.17
  › rustup: 1.24.3
  › rustc: 1.60.0
  › cargo: 1.60.0
  › Rust toolchain: stable-x86_64-pc-windows-msvc

Packages
  › @tauri-apps/cli [NPM]: 1.0.0-rc.10
  › @tauri-apps/api [NPM]: 1.0.0-rc.3
  › tauri [RUST]: 1.0.0-rc.10,
  › tauri-build [RUST]: 1.0.0-rc.8,
  › tao [RUST]: 0.8.4,
  › wry [RUST]: 0.16.2,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../build
  › devPath: http://localhost:3000/
  › framework: Svelte
  › bundler: Rollup

App directory structure
  ├─ .vscode
  ├─ build
  ├─ node_modules
  ├─ public
  ├─ scripts
  ├─ src
  └─ src-tauri
Done in 5.99s.

Stack trace

No response

Additional context

No response

[lucasfernog]

We'll need to revert this fix because it brings more issues than benefits, for now just use an async command until we can fix this either in tao or in Webview2.

[lanten]

@lucasfernog if i use async command, this will bring new problem in macos,

I use window-vibrancy to create a vibrant window in async command.

Then, i get an panick : "\"apply_vibrancy()\" can only be used on the main thread.", it seems that asynchronous commands cannot be used in this case.

I can only judge different environments in js and send different commands to achieve this effect.

[dceddia]

@lanten I ended up working around this by having 2 versions of my commands with some #cfg flags to enable one on Windows and the other on Mac. Something like this:

#[cfg(windows)]
#[tauri::command]
pub async fn is_overlay_hidden(overlay: State<'_, OverlayWrapper>) -> Result<bool, String> {
    Ok(overlay.is_hidden())
}

#[cfg(not(windows))]
#[tauri::command]
pub fn is_overlay_hidden(overlay: State<'_, OverlayWrapper>) -> Result<bool, String> {
    Ok(overlay.is_hidden())
}

This way the UI can call the same function on both platforms.

I'm only targeting Win + Mac right now and technically this would use the non-async function on linux too. I've no idea what actually needs to happen on Linux with this though. Just a heads up if it matters for your case!

[lanten]

@dceddia This is a valid temporary solution, it works well for me. thank you!