Skip to content
New issue

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

#

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

Already on GitHub? # 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.

# for free to join this conversation on GitHub. Already have an account? # 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