wry
wry copied to clipboard
tauri-apps
WebRTC support on Linux
I tested only on macOS. It might already work on other platforms.
Is your feature request related to a problem? Please describe. I want to use WebRTC
Describe the solution you'd like I don't have any preference. I just want to use WebRTC.
Describe alternatives you've considered
- With system webbrowser (doesn't work on macOS)
Notification.requestPermission() // => undefined navigator.mediaDevices // => undefined - Using another process I don't know any library to use WebRTC with VideoUI on desktop 😭
Additional context
It seems, the cause of this issue is this https://forums.developer.apple.com/thread/88052
And, the following might solve this issue on macOS (not tested). https://bugs.webkit.org/show_bug.cgi?id=208667#c17
There are similar issues in other repositories.
- https://github.com/patr0nus/DeskGap/issues/26#issuecomment-486463510 (someone mentioned "WkWebView's getUserMedia functionality is disabled, when embedded")
- https://github.com/zserge/webview/issues/368
So i found these additions to the Info.plist
<key>NSCameraUsageDescription</key>
<string>$(PRODUCT_NAME) Requires camera access in order to capture and transmit video</string>
<key>NSMicrophoneUsageDescription</key>
<string>$(PRODUCT_NAME) Requires microphone access in order to capture and transmit audio</string>
https://developer.apple.com/documentation/bundleresources/information_property_list/nscamerausagedescription?language=objc https://developer.apple.com/documentation/bundleresources/information_property_list/nsmicrophoneusagedescription?language=objc
@rajivshah3
regarding notifications @ken0x0a - we merged a cross-platform notification API: https://github.com/tauri-apps/tauri/pull/505
It will land in the next release.
I am wondering if we will have to roll our own: https://github.com/libp2p/rust-libp2p/issues/1066
Well, I believe that our new custom protocol allows for the secure context on all platforms. Still, we have not proven this to work, so am moving this issue over to WRY for tracking there.
WebRTC also is not supported by Webkit2GTK. It technically doesn't require permissions to work, but it's most commonly used with a webcam/mic input and those require permissions.
macOS update
The runtime requires some permissions. Adding an embed PLIST to the runtime fixed the issue for me.
You can give it a try with embed_plist
Sample PLIST
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSCameraUsageDescription</key>
<string>Request camera access for WebRTC</string>
<key>NSMicrophoneUsageDescription</key>
<string>Request microphone access for WebRTC</string>
</dict>
</plist>
Test app
#[cfg(target_os = "macos")]
embed_plist::embed_info_plist!("Info.plist");
fn main() -> wry::Result<()> {
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("Hello World")
.build(&event_loop)
.unwrap();
let _webview = WebViewBuilder::new(window)
.unwrap()
.with_url("https://test.webrtc.org/")?
.build()?;
event_loop.run(move |event, _, control_flow| {
*control_flow = ControlFlow::Poll;
match event {
Event::NewEvents(StartCause::Init) => println!("Wry application started!"),
Event::WindowEvent {
event: WindowEvent::CloseRequested,
..
} => *control_flow = ControlFlow::Exit,
_ => (),
}
});
}
Also, seems to works only over HTTPS, so doesn't work for custom protocol, so I think the wry job is pretty much done, only require the custom protocol support who I think should be moved to another issue.
Tauri should give the possibility to inject a PLIST at runtime for development. For bundled app, we already generate a plist, so maybe we should add it as a configuration object to request microphone, webcam access, so we could inject it automatically.
Edit: Looks like I've been able to get custom protocol to work. We need to make sure to use the host localhost in our custom protocol. So for example, instead of using wry:// as the entry point, we should use wry://localhost/, this way content, is processed as HTTPS.
It seems webkitgtk doesn't support webrtc. https://bugs.webkit.org/show_bug.cgi?id=194805
Found a bug tracker states webkitgtk does has webrtc support. https://bugs.webkit.org/show_bug.cgi?id=196222
I'll try to build it this night.
Regarding boring-ssl and its gpl nature, we aren't shipping it (just linking) so it will not impact us.
yeah I think you are right. We cannot distribute it for non-GPL apps because of it. Below is the status report from WPE but should hold the same to WebkitGtk https://wpewebkit.org/about/faq.html#what%E2%80%99s-the-status-regarding-webrtc%3F
Is there any solution connecting other languages implementation like SWIG? Seems like a workaround (but for temporary use might be usable)
Hiiii ^^
Can we rename this issue to "WebRTC support on Unices"?
It seems this issue is also talking about MacOS (which isn't Linux of course), soo it'll be great for clarity!!!
@lovelyyfiaaa Heyy :)
webrtc does work on macos, that's why the issue was renamed from WebRTC support to WebRTC support on Linux a few messages above (actually it was fixed a little bit before it was renamed)
@lovelyyfiaaa Heyy :) webrtc does work on macos, that's why the issue was renamed from
WebRTC supporttoWebRTC support on Linuxa few messages above (actually it was fixed a little bit before it was renamed)
Aaah, I seee. But I think we should do something to make this issue less confusing?
https://webrtc.rs/ seems usable now Can that be somehow used for Tauri?
Umm, how does it support Pipewire? It's required in Linux because of security requirements implemented in Wayland and Flatpak ^^
Ahh okay!! The codebase has no mention of it, so we should ask the devs first ^^
I'm opening https://github.com/webrtc-rs/webrtc/issues/231 nowww <3
I think a relevant issue for this would be: https://github.com/webrtc-rs/webrtc/issues/94 and the crates linked in that, none of them seem to explicitly support pipewire.
Also, unless i got it completely wrong, this issue shows that it's not ready for tauri at all, which means we have to keep working for webkitgtk, buuut last time i checked, they planned on enabling the gstreamer backend in the 2.38 :)
Regarding boring-ssl and its gpl nature, we aren't shipping it (just linking) so it will not impact us.
Ummm, I'm not a lawyer, buuut doesn't linking too trigger the GPL?
For proprieritary softwares, this is safe, as long as the company making the proprieritary part isn't hostile (for example Minecraft modders distribute mod patches and not the modified binaries), but this isn't the same case for crowd-enforced open source licenses right?
Also, unless i got it completely wrong, this issue shows that it's not ready for tauri at all, which means we have to keep working for webkitgtk,
Yep!! There's https://github.com/RustAudio/cpal/issues/554 but it seems it's not a finished issue yet?
Umm, what do you guys think about using QtWebEngine?
https://github.com/tauri-apps/tauri/issues/4554
Aha, yup!!! There isn't a good bindings library for Qt in Rust yet for noww. ^^
@yuluo-zy No, but we're somewhat optimistic that the next webkit2gtk version will add support for webrtc.
Oh i forgot to update my above message - Yes, initial support was added in 2.38 but it's hidden behind a build flag and so far not a single distro enables it. Therefore we unfortunately have to keep waiting...
Is there any action on this issue? I have just run into the same thing, and would really like this to work in Tauri.
My last comment is still accurate. We're still waiting for the next webkigtk update which hopefully has more complete webrtc support. (they have a ~6 month release schedule to always get a new release out before a new ubuntu version in case you're wondering)