KittyCAD / modeling-app

The KittyCAD modeling app.
https://kittycad.io/modeling-app/download
MIT License
282 stars 20 forks source link

RTCPeerConnection error on Linux builds #625

Open pierremtb opened 9 months ago

pierremtb commented 9 months ago

image

pierremtb commented 9 months ago

Reported on Fedora, Arch Linux, and Ubuntu

iterion commented 9 months ago

This is gonna be tricky to fix, I think: https://github.com/tauri-apps/wry/issues/85

The last comment says even the latest webviewgtk is still missing stable support. There is a flag that can be enabled, but since this is system install we'd have install a custom version maybe, I'm not even sure if that's doable or worth it if it's not stable.

adamchalmers commented 9 months ago

For now the quickest workaround for Linux users is the browser app. I think we should encourage Linux users to use the browser app for now. We should only show the banner that says "please use the native app" on MacOS and Windows.

jgomez720 commented 9 months ago

@adamchalmers agreed.

paultag commented 9 months ago

Under Linux, I believe it's using the https://webkitgtk.org/ backend (libwebkit2gtk-4.1-0 here I think), and quoth their website:

The web isn’t just for reading words. We drive development of the GStreamer WebKit backend and support full integration of video into page content and the HTML canvas element. Currently we are working to finish support for WebAudio and WebRTC.

The app was specifically failing with new RTCPeerConnection(), which is not something that should fail if we have WebRTC in the browser. I think we all just assumed this would always be the case, but alas.

Maybe we can determine if RTCPeerConnection === undefined and drop a more helpful error message or something?

Irev-Dev commented 9 months ago

Is there anything (in issue or something) we can follow so we know when they finish their support?

Irev-Dev commented 9 months ago

I think maybe we don't support linux in the short term, and in the longer term either a) They will get support because we'll properly support a browser version b) We might decide it's worth it to spin up an electron version 😢

paultag commented 9 months ago

From their docs:

Add initial implementation of WebRTC using GstWebRTC if GStreamer 1.20 is available, disabled by default via web view settings.

This gives me a bit of hope. I'm trying to find bugs in the bug tracker, maybe https://bugs.webkit.org/show_bug.cgi?id=235885 ?

It's funny - it should be possible to enable this somehow, the state of the world from the bug tracker makes it seem like we may be able to toggle this on?

paultag commented 9 months ago

Maybe https://www.youtube.com/watch?v=GfxOQbPNsUY too?

paultag commented 9 months ago

image

I won't be able to make progress on this tonight since the API is still not working right but I've been able to build it locally with the latest support. I'll get back to this one after the connection stuff; Let's see how far we can push it.

eric-schleicher commented 9 months ago

ok, registering same issue on fedora38 (nobara).

image

I'm 0-2 trying windows and linux in rapid succession. will try the browser app

paultag commented 9 months ago

I wasn't super great about updating this bug but here's the laydown of the current state:

On Linux, tauri (really wry) uses libwebkit2gtk. Specifically, the version of tauri we use (pre 2.0) uses a slightly older version of wry (libwebkit2gtk-4.0 vs the current main branch uses libwebkit2gtk-4.1). Additionally, webkit2gtk needs a gstreamer built with WebRTC support (this is the case in Debian at least, although it's part of the bad plugin set so it may be missing from Ubuntu at minimum), and webkit2gtk needs to be built with ENABLE_WEB_RTC=ON and USE_GSTREAMER_WEBRTC=ON (not the case for Debian, but I haven't sent a patch yet).

Lastly, the runtime needs to enable WebRTC for webkit2gtk (it's not on by default) which involves toggling a config.

Here's a diff that I had locally when testing this

diff --git a/src-tauri/src/main.rs b/src-tauri/src/main.rs
index 5ca0ed8..a0ebb82 100644
--- a/src-tauri/src/main.rs
+++ b/src-tauri/src/main.rs
@@ -6,6 +6,10 @@ use std::io::Read;
 use anyhow::Result;
 use oauth2::TokenResponse;
 use tauri::{InvokeError, Manager};
+
+#[cfg(target_os = "linux")]
+use webkit2gtk::WebViewExt;
+
 const DEFAULT_HOST: &str = "https://api.kittycad.io";

 /// This command returns the a json string parse from a toml file at the path.
@@ -130,13 +134,23 @@ async fn get_user(
 fn main() {
     tauri::Builder::default()
         .setup(|app| {
+            let window = app.get_window("main").unwrap();
+
             #[cfg(debug_assertions)] // only include this code on debug builds
             {
-                let window = app.get_window("main").unwrap();
                 // comment out the below if you don't devtools to open everytime.
                 // it's useful because otherwise devtools shuts everytime rust code changes.
                 window.open_devtools();
             }
+
+            #[cfg(target_os = "linux")]
+            window.with_webview(|webview| {
+                let view = webview.inner();
+                if let Some(settings) = WebViewExt::settings(&*view) {
+                    settings.set_enable_webrtc(true);
+                }
+            });
+
             Ok(())
         })
         .invoke_handler(tauri::generate_handler![

However, this requires a new version of wry, which is only in tauri 2.0+, so I did a very bad thing to try to coax wry into doing the right thing, but I feel bad posting that diff. I'll post it but you're going to have to click through a warning to see it:

🚨 ⚠️⚠️ warranty voiding shit here ⚠️⚠️ 🚨
diff --git a/src-tauri/src/main.rs b/src-tauri/src/main.rs
index 5ca0ed8..e99af03 100644
--- a/src-tauri/src/main.rs
+++ b/src-tauri/src/main.rs
@@ -6,6 +6,24 @@ use std::io::Read;
 use anyhow::Result;
 use oauth2::TokenResponse;
 use tauri::{InvokeError, Manager};
+
+#[cfg(target_os = "linux")]
+mod platform_linux {
+    use webkit2gtk::{Settings};
+
+    #[link(name = "webkit2gtk-4.0")]
+    extern "C" {
+        fn webkit_settings_set_enable_webrtc(settings: *mut usize, enabled: bool);
+    }
+
+    pub fn set_enable_webrtc(settings: &mut Settings, enabled: bool) {
+        unsafe {
+            let ptr: *const *mut usize = std::mem::transmute(settings);
+            webkit_settings_set_enable_webrtc(*ptr, enabled);
+        }
+    }
+}
+
 const DEFAULT_HOST: &str = "https://api.kittycad.io";

 /// This command returns the a json string parse from a toml file at the path.
@@ -130,13 +148,25 @@ async fn get_user(
 fn main() {
     tauri::Builder::default()
         .setup(|app| {
+            let window = app.get_window("main").unwrap();
+
             #[cfg(debug_assertions)] // only include this code on debug builds
             {
-                let window = app.get_window("main").unwrap();
                 // comment out the below if you don't devtools to open everytime.
                 // it's useful because otherwise devtools shuts everytime rust code changes.
                 window.open_devtools();
             }
+
+            #[cfg(target_os = "linux")]
+            let _ = window.with_webview(|webview| {
+                use webkit2gtk::WebViewExt;
+
+                let view = webview.inner();
+                if let Some(mut settings) = WebViewExt::settings(&*view) {
+                    platform_linux::set_enable_webrtc(&mut settings, true);
+                }
+            });
+
             Ok(())
         })
         .invoke_handler(tauri::generate_handler![
(this is bad because we blindly deref the `webkit2gtk::Settings` wrapper, to get at `Settings.inner.inner`, which is the pointer we need. This isn't exported (kinda obviously imho), so we have to `transmutate` ourselves through the pain. This isn't a good long term solution, but we do get further.)

I hit an issue because gstreamer on my system was built against libsoup3, and the older 4.0 version uses libsoup2. I was going to start rebuilding gstreamer but I thought the better of it, and figured the real solution is to roll KCMA forward to tauri 2.0 when it's ready.

Once we roll forward a bit I was going to start sending patches with my KittyCAD hat on to Debian and try to get builds on Linux working (and statically built so we don't have to rebuild archive packages on foreign distros), but until then I'm off this issue for the time being; I don't think this will be a long-term blocker or some technical challenge, at this point it's more waiting for releases to drop.

adamchalmers commented 9 months ago

@JonasKruckenberg Hi! FYI, the comment from @paultag directly above is what I was talking with you about on twitter.

JonasKruckenberg commented 9 months ago

Linux am I right? 🙃 Sorry that you guys had to go through this, but seems like you figured it out!

paultag commented 9 months ago

@JonasKruckenberg to be fair it only took a few hours (although I have a hunch being a Debian Developer helped a lot here) -- it really wasn't an issue or even something I felt the need to file an issue about with Tauri.

That being said, just to communicate more explicitly the thing we're waiting for on Linux support (or rather; for me to start working on Linux support for KCMA) is either a release of tauri classic / 1.0 (given we're on version = "1.5.0" today), or 2.0 when we'd likely have to undergo porting work, either version of which, which brings in a wry version that in turn brings in a libwebkit2gtk version of 4.1 rather than 4.0, including the exposed set_enable_webrtc flag on the Settings object.

Thanks for maintaining Tauri, it's great stuff!

paultag commented 8 months ago

As an update for folks watching the issue: I just checked on this issue again since we updated Tauri at some point.

We're still pinned against webkit2gtk = { version = "0.18.2", features = [ "v2_22" ] } via tauri, which is older than the changes we need behind feature v2_38 in webkit2gtk. Still in a holding pattern here!

dcl commented 2 weeks ago

are there any updates on this? it looks like tauri v2 pins webkit2gtk = { version = "=2.0.1", features = [ "v2_38" ] }, so #1400 should have unblocked the issues mentioned upthread