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.

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

System Proxy Issue on Ubuntu 22.04 After webkit2gtk Upgrade from 4.0 to 4.1 #1382

Open
lanyeeee opened this issue Oct 7, 2024 · 2 comments

Comments

@lanyeeee
Copy link

lanyeeee commented Oct 7, 2024

Describe the bug

In this issue, I discovered that when using Ubuntu, Tauri v2 cannot automatically use the system proxy, while Tauri v1 can.

Then I noticed that Tauri v1 uses wry v0.24.11, which is significantly behind Tauri v2.
Through my testing, I found that the next version after v0.24.11, v0.25.0, already has the issue where it cannot automatically use the system proxy. The main update in v0.25.0 was the upgrade of webkit2gtk-rs from 0.18.2 to 0.19.1, which caused webkit2gtk to upgrade from 4.0 to 4.1.
It is likely that this issue with automatically using the system proxy was caused by the upgrade from webkit2gtk 4.0 to 4.1.

I noticed that the latest wry already supports manually setting a proxy.
This feature is not supported in webkit2gtk4.0 but is available in 4.1.
After testing, I confirmed that the manual proxy setting feature in latest wry works properly.
However, latest wry can not automatically use the system proxy, it either requires users to manually specify the proxy or does not use any proxy at all.
The software I am developing relies on this automatic proxy feature.

Steps To Reproduce

To reproduce this issue on Ubuntu 22.04, follow these steps:

  1. Create a new project:
cargo new wry-proxy-issue
  1. Modify Cargo.toml:
[package]
name = "wry-proxy-issue"
version = "0.1.0"
edition = "2021"

[dependencies]
wry = "=0.25.0"
  1. Modify main.rs:
fn main() -> Result<(), Box<dyn std::error::Error>> {
    use wry::{
        application::{
            event::{Event, StartCause, WindowEvent},
            event_loop::{ControlFlow, EventLoop},
            window::WindowBuilder,
        },
        webview::WebViewBuilder,
    };

    let event_loop = EventLoop::new();
    let window = WindowBuilder::new()
        .with_title("Proxy Test")
        .build(&event_loop)?;

    let _webview = WebViewBuilder::new(window)?
        .with_url("https://tauri.app/")?
        .build()?;

    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;

        match event {
            Event::NewEvents(StartCause::Init) => println!("Wry has started!"),
            Event::WindowEvent {
                event: WindowEvent::CloseRequested,
                ..
            } => *control_flow = ControlFlow::Exit,
            _ => (),
        }
    });
}
  1. Set up a system proxy(in my case, I used http://127.0.0.1:7890).

image

  1. Run the project:
cargo run
  1. You should see an error in the webview:

image

If you downgrade to wry = "=0.24.11" in Cargo.toml, the issue does not occur, and the proxy works as expected.

This issue persists in the latest version (wry 0.45.0) as well.
To reproduce this issue in the latest wry is basically the same as the steps above, except that the contents of main.rs and Cargo.toml are different.

Modify Cargo.toml:

[package]
name = "wry-proxy-issue"
version = "0.1.0"
edition = "2021"

[dependencies]
tao = "0.30.3"
wry = "0.45.0"

Modify main.rs:

use tao::event::{Event, StartCause, WindowEvent};
use tao::event_loop::{ControlFlow, EventLoop};
use tao::window::WindowBuilder;
use wry::WebViewBuilder;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let event_loop = EventLoop::new();
    let window = WindowBuilder::new()
        .with_title("Proxy Test")
        .build(&event_loop)?;

    let builder = {
        use tao::platform::unix::WindowExtUnix;
        use wry::WebViewBuilderExtUnix;
        let vbox = window.default_vbox().unwrap();
        WebViewBuilder::new_gtk(vbox)
    };

    let _webview = builder
        .with_url("https://tauri.app/")
        .build()?;

    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;

        match event {
            Event::NewEvents(StartCause::Init) => println!("Wry has started!"),
            Event::WindowEvent {
                event: WindowEvent::CloseRequested,
                ..
            } => *control_flow = ControlFlow::Exit,
            _ => (),
        }
    });
}

After running it you will see the same error as above in the webview.
And to resolve this in latest wry is very simple.
Just set the proxy manually. Change the code in main.rs to the following:

use tao::event::{Event, StartCause, WindowEvent};
use tao::event_loop::{ControlFlow, EventLoop};
use tao::window::WindowBuilder;
use wry::{ProxyConfig, ProxyEndpoint, WebViewBuilder};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let event_loop = EventLoop::new();
    let window = WindowBuilder::new()
        .with_title("Proxy Test")
        .build(&event_loop)?;

    let builder = {
        use tao::platform::unix::WindowExtUnix;
        use wry::WebViewBuilderExtUnix;
        let vbox = window.default_vbox().unwrap();
        WebViewBuilder::new_gtk(vbox)
    };

    let http_proxy = ProxyConfig::Http(ProxyEndpoint {
        host: "127.0.0.1".to_string(),
        port: "7890".to_string(),
    });

    let _webview = builder
        .with_proxy_config(http_proxy)
        .with_url("https://tauri.app/")
        .build()?;

    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;

        match event {
            Event::NewEvents(StartCause::Init) => println!("Wry has started!"),
            Event::WindowEvent {
                event: WindowEvent::CloseRequested,
                ..
            } => *control_flow = ControlFlow::Exit,
            _ => (),
        }
    });
}

Expected behavior

I expect the latest wry can automatically use the system proxy when no manual proxy is configured, just as it did in version v0.24.11.

But now latest wry either requires users to manually specify the proxy or does not use any proxy at all, lacking the option to automatically use the system proxy.

Is the inability to automatically use the proxy a problem with webkit2gtk4.1 itself? Can wry automatically use the system proxy?

Screenshots

Platform and Versions (please complete the following information):

  • OS: Linux Mint 21.2.0 x86_64 (X64)
    ✔ webkit2gtk-4.1: 2.44.2
    ✔ rsvg2: 2.52.5
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)

Additional context

@lanyeeee
Copy link
Author

lanyeeee commented Oct 8, 2024

I tried Luakit, a browser based on Webkit2gtk. Starting from version 2.3.4, it uses Webkit2gtk 4.1.

I installed a fresh Ubuntu 24.04 and directly installed luakit 2.3.6 via apt. I noticed that luakit 2.3.6 automatically detects and uses the system proxy. Does this mean that Webkit2gtk 4.1 has the capability to automatically detect and use the system proxy, right? Or did I misunderstand something?

@lanyeeee
Copy link
Author

lanyeeee commented Oct 8, 2024

The reason I tested Luakit on Ubuntu 24.04 instead of Ubuntu 22.04 in my previous comment is that Ubuntu 24.04 provides version 2.3.6 of Luakit through apt, which allows me to avoid manually compiling Luakit.

However, when I went back to Ubuntu 22.04, manually compiled and ran Luakit, the system proxy issue reappeared.

So I went back to Ubuntu 24.04 again, try to reproduce the issue, it was gone.

Now the issue is now quite clear—it is a problem with webkit2gtk4.1 on Ubuntu 22.04.

I’m not entirely sure why, but since libwebkit2gtk4.1 is built-in on Ubuntu 24.04 and has to be manually installed on Ubuntu 22.04, that could be the reason, perhaps?

@lanyeeee lanyeeee changed the title System Proxy Auto-use Issue in wry After webkit2gtk Upgrade from 4.0 to 4.1 System Proxy Issue on Ubuntu 22.04 After webkit2gtk Upgrade from 4.0 to 4.1 Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant