[bug] Calls to custom schemes freeze the application

[Trivernis]

Describe the bug

When fetching data via custom schemes with slightly longer running logic handling the requests the application freezes for the duration of the request. This behaviour seems to be more extreme when having multiple requests to custom schemes at once. I observed this behaviour with custom schemes being used in image elements but I'd imagine that this is a general problem.

Reproduction

1. Register a custom scheme that runs for a while (e.g. by using sleep calls)
2. Call this custom scheme (by registering a scheme url as an image source for example)
3. The application freezes for the duration of the request

Expected behavior

Calls to custom schemes should not freeze the application. If this is unavoidable with synchronous handlers, at least having an option for using asynchronous calls would be nice.

Platform and versions

Operating System - Arch Linux, version Rolling Release X64

Node.js environment
  Node.js - 16.13.2
  @tauri-apps/cli - 1.0.0-beta.10
  @tauri-apps/api - 1.0.0-beta.8

Global packages
  npm - 8.1.2
  yarn - 1.22.17

Rust environment
  rustc - 1.58.1
  cargo - 1.58.0

App directory structure
/src-tauri
/src
/node_modules
/.idea
/.angular
/dist

App
  tauri.rs - 1.0.0-beta.8
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self' once: thumb: content:
  distDir - ../dist/mediarepo-ui
  devPath - http://localhost:4200
  framework - Angular
  bundler - Webpack

Stack trace

No response

Additional context

I've reproduced this behaviour with a minimal tauri app. My real use case is calling custom schemes that then use an asynchronous runtime to block on asynchronous callbacks.

[amrbashir]

I think this should be fixed in wry.

[amrbashir]

/upstream tauri-apps/wry

[tauri-apps[bot]]

I have created an upstream issue at https://github.com/tauri-apps/wry/issues/511, I will notify you once it is resolved.

[lucasfernog]

Closed by #7754 (will be fixed on v2).