tauri-apps/wry

Doesn't work

andrewbaxter opened this issue · 6 comments

andrewbaxter commented

Describe the bug
Sorry, I know this is a terrible title. I just tried the simple example and all I get is a blank (gtk beige) window with nothing in it. No errors, no log messages, I right click and select "Inspect Element" and the beige window stays the same, although the right click menu changes to show things like "Network" and "Elements", "Add", "Forced Pseudo-class" depending on where I right click so I presume the developer window is open.

Steps To Reproduce
cargo build then ./wry1 (what I named it):

// Copyright 2020-2023 Tauri Programme within The Commons Conservancy
// SPDX-License-Identifier: Apache-2.0 SPDX-License-Identifier: MIT
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("http://tauri.app")
            .with_drag_drop_handler(|e| {
                match e {
                    wry::DragDropEvent::Enter { paths, position } => {
                        println!("DragEnter: {position:?} {paths:?} ")
                    },
                    wry::DragDropEvent::Over { position } => println!("DragOver: {position:?} "),
                    wry::DragDropEvent::Drop { paths, position } => {
                        println!("DragDrop: {position:?} {paths:?} ")
                    },
                    wry::DragDropEvent::Leave => println!("DragLeave"),
                    _ => { },
                }
                true
            })
            .build()?;
    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;
        if let Event::WindowEvent { event: WindowEvent::CloseRequested, .. } = event {
            *control_flow = ControlFlow::Exit
        }
    });
}

Expected behavior

  1. I'd expect some sort of logs if something went wrong, somewhere. Is it possible to hook up a log callback, or direct logging somewhere?
  2. The tauri website to show up.

Screenshots
image

Platform and Versions (please complete the following information):
OS: Arch
Rustc: rustc 1.76.0 (07dca489a 2024-02-04)

Additional context
I just cloned the repo (4c88c66) and did cargo build --example simple and same thing.

I tried http and https in case that's relevant, all the examples have http.

I spent a while trying to get my app working which I had based on the transparent example, before walking things back until I got here. With the transparent example I get a black window instead of beige.

FabianLars commented

Can you try running the compiled binary with WEBKIT_DISABLE_COMPOSITING_MODE=1 please? This looks like the typical webkitgtk issue to me. (Are you using an nvidia gpu?)

andrewbaxter commented

Fast! That works! Yes, with mesa/nouveau.

So I assume the answer is that

  1. Everything was working nominally, but some low level graphics issue prevented it from displaying. So nothing actually knew that there was an issue (or maybe the error happened in the compositor or x or something) => no app logging.
  2. This is a known bug expected to be fixed soon? Hence no warning on the repo page. FWIW I'm not great at reading things through 100%, but if there were a warning banner in the first page I probably would have seen it.
andrewbaxter commented

Well, transparency doesn't work, but I assume that's an expected consequence of WEBKIT_DISABLE_COMPOSITING_MODE=1.

andrewbaxter commented

Sorry, not sure what to do here exactly. I presume this affects a minority of nvidia gpus... or maybe it's a mesa thing, or maybe I'm unlucky.

Would it be worth adding a warning somewhere in the readme and closing this? Or maybe this issue is enough of a warning for people who encounter this issue? Given its history, I don't expect the bug to ever be fixed.

FabianLars commented

Sorry for the delay here, you figured it out already but i'm still gonna answer:

This is a known bug expected to be fixed soon?

Known? Yes. Expect to be fixed soon or ever? Sadly not.

Can you try WEBKIT_DISABLE_DMABUF_RENDERER=1 instead of WEBKIT_DISABLE_COMPOSITING_MODE=1?

I presume this affects a minority of nvidia gpus

This specific one maybe, but really all nvidia user has some issues with webkitgtk.

Would it be worth adding a warning somewhere in the readme and closing this?

Considering that webkitgtk seems to get more and more unstable we will document platform limitations, including a huge warning about linux support as a whole, in the v2 docs, but you're right that porting those then to wry directly is a good idea too.