[bug][v2] @tauri-apps/plugin-shell's open called twice while the Explorer is still open freezes the app

[martpie]

Describe the bug

WTTS, this happens on Windows only. The URL in question is a directory, not a file (for example: C:\Users\<user>\AppData\Roaming\<identifier>)

Here is a screencast:

8mb.video-kcW-fMkvaf8w.mp4

Reproduction

From any Tauri UI, calls import { open } from '@tauri-apps/plugin-shell'; and try to open the same link twice.

When the Explorer is closed, the link works flawlessly. When the explorer is already opened, the app will freeze.

Expected behavior

No response

Full tauri info output

yarn run v1.22.19
$ tauri info

[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 123.0.2420.65
    ✔ MSVC:
        - Visual Studio Build Tools 2019
        - Visual Studio Build Tools 2022
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.11.1
    - yarn: 1.22.19
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 2.0.0-beta.13
    - tauri-build [RUST]: 2.0.0-beta.10
    - wry [RUST]: 0.37.0
    - tao [RUST]: 0.26.1
    - @tauri-apps/api [NPM]: 2.0.0-beta.6
    - @tauri-apps/cli [NPM]: 2.0.0-beta.9

[-] App
    - build-type: bundle
    - CSP: default-src 'none'; img-src 'self' data:; media-src 'self' asset: https://asset.localhost http://asset.localhost; child-src 'self'; object-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; connect-src ipc: http://ipc.localhost 'self' https://api.github.com; font-src 'self' data:
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite
Done in 8.04s.

### Stack trace

_No response_

### Additional context

_No response_

[amrbashir]

I can't reproduce at all, try running cargo update inside src-tauri just to make sure you're using the latest version of the plugin and if it still doesn't work, can you please share a minimal repro?

[martpie]

Sorry for the late reply, here is a reproduction: https://github.com/martpie/tauri-shell-open-freeze-repro

yarn run v1.22.19
$ tauri info

[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 124.0.2478.67
    ✔ MSVC:
        - Visual Studio Build Tools 2019
        - Visual Studio Build Tools 2022
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.11.1
    - yarn: 1.22.19
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 2.0.0-beta.16
    - tauri-build [RUST]: 2.0.0-beta.13
    - wry [RUST]: 0.39.3
    - tao [RUST]: 0.27.1
    - @tauri-apps/api [NPM]: 2.0.0-beta.11
    - @tauri-apps/cli [NPM]: 2.0.0-beta.13

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite
Done in 6.55s.

[martpie]

Not really sure if that can help, but I see the following after hard killing the app:

[0430/212358.153:ERROR:window_impl.cc(121)] Failed to unregister class Chrome_WidgetWin_0. Error = 0

[FabianLars]

Nope, that one can be ignored, it's just a consequence of closing the webview.

[amrbashir]

A PR is open upstream Byron/open-rs#98

[amrbashir]

try it by adding the following in Cargo.toml and then runcargo update -p open in src-tauri

[patch.crates-io]
open = { git = "https://github.com/amrbashir/open-rs", branch = "fix/windows/shell-execute-freeze" }

[amrbashir]

PR is merged and released, run cargo update -p open in src-tauri

[martpie]

Thank you!

[thewh1teagle]

@amrbashir,

Now that we've resolved this issue and encountered a similar one before, can we make error details clearer for next time? It seems you've identified the root cause. As for the other issue causing the app to hang, is there a way for regular users or the app itself to gather crash or event logs?

btw, I updated open crate, and it seems like the issue is fixed now!

[amrbashir]

Unfortunately this bug doesn't have any errors, it is just that the win32 native API ShellExecuteW had undocumented behavior that it may block when opening directories, specifically when calling it a second time, and the function never returns causing the whole app to freeze.

I know that we have useless error messages in the past but we are trying to change that one step at a time, if there is any unclear error messages, please let us know.

[thewh1teagle]

Unfortunately this bug doesn't have any errors, it is just that the win32 native API ShellExecuteW had undocumented behavior that it may block when opening directories, specifically when calling it a second time, and the function never returns causing the whole app to freeze.

I know that we have useless error messages in the past but we are trying to change that one step at a time, if there is any unclear error messages, please let us know.

I mean that i'm encountering another bug that's causing hang crash like this one, and I'm wondering if tauri can capture crash logs so I can pinpoint where they're occurring for users. I've set up a panic hook, but it doesn't log anything in cases of hang crashes.

Regarding the fix for this issue: The newer version of the open library opens new Explorer windows even when opening the same path, whereas previously it just focused on the already opened Explorer path.

[amrbashir]

I mean that i'm encountering another bug that's causing hang crash like this one, and I'm wondering if tauri can capture crash logs so I can pinpoint where they're occurring for users. I've set up a panic hook, but it doesn't log anything in cases of hang crashes.

Unfortunately no, at least I am not aware of one. Freezes usually mean a thread is probably in an infinite loop waiting for something, for example, a mutex deadlock.

Now when a thread is frozen, usually the main thread, Windows will still send messages to that thread but since the thread is frozen, it won't respond in time and Windows will deem this application Not Responding and will try to kil it. There is no actual crash involved. You migt find some info in Windows Event Logger but it won't pin point what caused the freeze of thread.

Regarding the fix for this issue: The newer version of the open library opens new Explorer windows even when opening the same path, whereas previously it just focused on the already opened Explorer path.

Yes, that's expected, otherwise it will block and freeze

[martpie]

There was a similar freeze recently when trying to pop a native context menu. I have not seen this kind of issues in Electron or QT for example.

Pardon my ignorance, I'm a thread-noob:

• why is this freezing the main app if a thread is stuck?
• is it possible to "timeout" a thread? Those are short-lived operations, and I would expect them to succeed or fail in less than a second.

[amrbashir]

There was a similar freeze recently when trying to pop a native context menu. I have not seen this kind of issues in Electron or QT for example.

It is possible they might have had these issues long time ago and got fixed or they are super developers who are aware of these issues. I myself make mistakes and discover new things as more bug reports come along, so I can't guarantee this will be the last bug.

Pardon my ignorance, I'm a thread-noob:

• why is this freezing the main app if a thread is stuck?
• is it possible to "timeout" a thread? Those are short-lived operations, and I would expect them to succeed or fail in less than a second.

Generally when a thread is frozen, other threads can still operate just fine. It is also possible to timeout a thread and abort it.

Anyways, we were calling ShellExecuteW directly, we are not using thread, but the documentation doesn't have enough information about why this freeze happens anyways.

[martpie]

Thank you for your work! I was just curious how things could work under the hood :)