Package version: webview_all / webview_all_linux 1.4.1
Environment:
- WSL2 Ubuntu (also worth testing on native Linux)
- webkit2gtk-4.1 version 2.52.6 (pkg-config --modversion webkit2gtk-4.1)
Problem:
Any page loaded in the widget that tries to use WebRTC (e.g. new RTCPeerConnection(...)) fails with:
Unhandled Promise Rejection: TypeError: undefined is not a constructor (evaluating 'new this.RTCPeerConnection(rtcConfiguration)')
window.RTCPeerConnection is undefined in the loaded page's JS context, even though the underlying libwebkit2gtk (2.52.6) fully supports WebRTC.
Root cause:
WebKitGTK's WebKitSettings has an enable-webrtc property (available since WebKitGTK 2.38) whose documented default value is FALSE: https://webkitgtk.org/reference/webkit2gtk/stable/property.Settings.enable-webrtc.html
webview_all_linux's native plugin code never calls webkit_settings_set_enable_webrtc() anywhere, and no equivalent option is exposed through the Dart API (LinuxWebViewControllerCreationParams, WindowsWebViewController-style settings, etc.). Since the setting defaults to false and nothing turns it
on, RTCPeerConnection is never exposed to page JS.
Reproduction:
- Load any page (local file:// or remote) that calls new RTCPeerConnection(...).
- Observe the TypeError: undefined is not a constructor error.
Expected: WebRTC should be usable, either by defaulting enable-webrtc to true when creating the webview, or by exposing it as a configurable creation parameter (similar to allowFileAccessFromFileUrls/allowUniversalAccessFromFileUrls, which are already exposed on
LinuxWebViewControllerCreationParams).
Suggested fix (native code, webview_all_linux/linux/src/webview/webview_method_handler.cc): near where the other WebKitSettings are applied (e.g. webkit_settings_set_allow_universal_access_from_file_urls), add:
webkit_settings_set_enable_webrtc(settings, TRUE);
ideally gated behind a new Dart-exposed creation parameter rather than hardcoded, mirroring how the existing file-access flags are exposed.
Package version: webview_all / webview_all_linux 1.4.1
Environment:
Problem:
Any page loaded in the widget that tries to use WebRTC (e.g. new RTCPeerConnection(...)) fails with:
Unhandled Promise Rejection: TypeError: undefined is not a constructor (evaluating 'new this.RTCPeerConnection(rtcConfiguration)')
window.RTCPeerConnection is undefined in the loaded page's JS context, even though the underlying libwebkit2gtk (2.52.6) fully supports WebRTC.
Root cause:
WebKitGTK's WebKitSettings has an enable-webrtc property (available since WebKitGTK 2.38) whose documented default value is FALSE: https://webkitgtk.org/reference/webkit2gtk/stable/property.Settings.enable-webrtc.html
webview_all_linux's native plugin code never calls webkit_settings_set_enable_webrtc() anywhere, and no equivalent option is exposed through the Dart API (LinuxWebViewControllerCreationParams, WindowsWebViewController-style settings, etc.). Since the setting defaults to false and nothing turns it
on, RTCPeerConnection is never exposed to page JS.
Reproduction:
Expected: WebRTC should be usable, either by defaulting enable-webrtc to true when creating the webview, or by exposing it as a configurable creation parameter (similar to allowFileAccessFromFileUrls/allowUniversalAccessFromFileUrls, which are already exposed on
LinuxWebViewControllerCreationParams).
Suggested fix (native code, webview_all_linux/linux/src/webview/webview_method_handler.cc): near where the other WebKitSettings are applied (e.g. webkit_settings_set_allow_universal_access_from_file_urls), add:
webkit_settings_set_enable_webrtc(settings, TRUE);
ideally gated behind a new Dart-exposed creation parameter rather than hardcoded, mirroring how the existing file-access flags are exposed.