Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

File uri causes panic in attach_ipc_handler #1255

Open
andrewbaxter opened this issue May 9, 2024 · 5 comments
Open

File uri causes panic in attach_ipc_handler #1255

andrewbaxter opened this issue May 9, 2024 · 5 comments
Labels
type: bug

Comments

@andrewbaxter
Copy link

Describe the bug
I'm using a file:// uri for the webview, and attach an IPC handler. When I run the app it panics at

thread 'main' panicked at /home/.../.cargo/registry/src/index.crates.io-6f17d22bba15001f/wry-0.39.4/src/webkitgtk/mod.rs:531:16:
called `Result::unwrap()` on an `Err` value: http::Error(InvalidUri(InvalidFormat))
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::result::unwrap_failed
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1649:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1073:23
   4: wry::webkitgtk::InnerWebView::attach_ipc_handler::{{closure}}
             at /home/.../.cargo/registry/src/index.crates.io-6f17d22bba15001f/wry-0.39.4/src/webkitgtk/mod.rs:528:13

which is

            Request::builder()
              .uri(webview.uri().unwrap().to_string())
              .body(js.to_string())
              .unwrap(),

Steps To Reproduce

Expected behavior

  1. I'd expect the request to be built successfully. Seems like an http issue parse::<Uri> fails to parse uris with triple slash after scheme hyperium/http#323
  2. Failing that, I'd be happy with a fake/standin/override url. I'm only using the body of the IPC request (how common is needing the URL?)

Screenshots

Platform and Versions (please complete the following information):
OS: Arch
Rustc: 1.76.0

Additional context
@andrewbaxter
Copy link
Author

Looks like they're open to PRs... I'll try to take a look, but one more item in my growing backlog.

@amrbashir
Copy link
Member

Can you please show a full reproduction example?

@andrewbaxter
Copy link
Author 

use tao::{
    event::{
        Event,
        WindowEvent,
    },
    event_loop::{
        ControlFlow,
        EventLoop,
    },
    platform::unix::WindowExtUnix,
    window::WindowBuilder,
};
use wry::{
    WebViewBuilder,
    WebViewBuilderExtUnix,
};

fn main() -> wry::Result<()> {
    let event_loop = EventLoop::new();
    let window = WindowBuilder::new().build(&event_loop).unwrap();
    let _webview =
        WebViewBuilder::new_gtk(window.default_vbox().unwrap())
            .with_url(format!("file://{}/examples/test.html", env!("CARGO_MANIFEST_DIR")))
            .with_ipc_handler(|_r| { })
            .build()?;
    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;
        if let Event::WindowEvent { event: WindowEvent::CloseRequested, .. } = event {
            *control_flow = ControlFlow::Exit
        }
    });
}

with html

<html>
  <body>
    <script>
      window.ipc.postMessage("");
    </script>
  </body>
</html>

@amrbashir
Copy link
Member

I guess we need to fix this panic and reduce the number of .unwrap() calls we have.

anyways, iirc file:// is not supported on all webviews and I'd recommend using a custom protocol to serve your asserts, see https://github.com/tauri-apps/wry/blob/dev/examples/custom_protocol.rs example

@andrewbaxter
Copy link
Author

Yeah, and for error logging... in my case I only need Linux though and even with a custom protocol (can I use file:// as a custom protocol?) I'd want the sorts of uris that cause the panic here. I'm working on a fix for the http issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@andrewbaxter @amrbashir