Reported by rgadagno7123 in #agent-windows (Discord, message 1536413550325670009).
Report (PII-redacted):
I did inspect elements in the breeze viewer and saw this WebRTC connection failed:
ReferenceError: Can't find variable: RTCPeerConnection
ut — index-BX25cdYu.js:10:62218
Filed automatically by @breeze-discord triage. Verify and add labels/repro as needed.
Triage analysis
The reported console line 'WebRTC connection failed: ReferenceError: Can't find variable: RTCPeerConnection' is not a browser message — it's the exact string logged in apps/viewer/src/lib/transports/webrtc.ts's catch block (console.warn('WebRTC connection failed:', err)) when createWebRTCSession's unguarded new RTCPeerConnection(...) (apps/viewer/src/lib/webrtc.ts:101) throws. The phrasing 'Can't find variable: X' is JavaScriptCore's ReferenceError format, not V8 (Chrome) or SpiderMonkey (Firefox), which both say 'X is not defined'. That points to the error actually occurring inside the native Breeze Viewer desktop app's embedded WebView, not the poster's browser tab. apps/viewer/src-tauri/Cargo.lock confirms the Linux build of that Tauri app links webkit2gtk (with javascriptcore-rs as its JS engine) — this is the WebView Tauri uses on Linux (an AppImage per the docs' Viewer Installers table). Depending on the distro's webkit2gtk/GStreamer build, RTCPeerConnection can be entirely absent as a global, so WebRTC can never start. The code does catch this and returns null so DesktopViewer.tsx's connect() (lines 913-919) falls back to the WebSocket/JPEG transport, but nothing detects/warns about missing WebRTC support up front, and there's no documentation of this Linux WebView limitation. The user's cross-platform pattern (Windows+Chrome/WebView2 works, Debian+Firefox/Chrome via the same native Viewer app fails) is consistent with this being a WebView-engine gap on Linux rather than a TURN/network issue.
Affected code
apps/viewer/src/lib/webrtc.ts:101 — new RTCPeerConnection(...) called with no feature-detection guardapps/viewer/src/lib/transports/webrtc.ts:186-201 — catch block logs 'WebRTC connection failed:' + err — matches the reported console line verbatim, and swallows non-Agent/SessionEnded errors, returning nullapps/viewer/src/components/DesktopViewer.tsx:913-919 — connect() falls back to connectWebSocket only after webrtcOk is falsy, i.e. after this exact ReferenceError is caughtapps/viewer/src-tauri/Cargo.lock:5302-5324 — webkit2gtk (+ javascriptcore-rs) is a dependency of the Linux Viewer build — the WebView/engine that produces 'Can't find variable' style ReferenceErrors
Potential fix
Feature-detect RTCPeerConnection before calling createWebRTCSession (e.g. if (typeof RTCPeerConnection === 'undefined') return null early in webrtc.ts) so the viewer skips straight to the WebSocket fallback with a clear log/UI hint ('WebRTC unsupported on this system, using WebSocket fallback') instead of relying on catching a ReferenceError, and document the webkit2gtk/GStreamer WebRTC dependency for the Linux AppImage build.
Triage analysis, affected code, and fix sketch above were produced by automated investigation (@breeze-discord). Verify before relying on them.
Reported by rgadagno7123 in #agent-windows (Discord, message 1536413550325670009).
Report (PII-redacted):
I did inspect elements in the breeze viewer and saw this WebRTC connection failed:
ReferenceError: Can't find variable: RTCPeerConnection
ut — index-BX25cdYu.js:10:62218
Filed automatically by @breeze-discord triage. Verify and add labels/repro as needed.
Triage analysis
The reported console line 'WebRTC connection failed: ReferenceError: Can't find variable: RTCPeerConnection' is not a browser message — it's the exact string logged in apps/viewer/src/lib/transports/webrtc.ts's catch block (console.warn('WebRTC connection failed:', err)) when createWebRTCSession's unguarded
new RTCPeerConnection(...)(apps/viewer/src/lib/webrtc.ts:101) throws. The phrasing 'Can't find variable: X' is JavaScriptCore's ReferenceError format, not V8 (Chrome) or SpiderMonkey (Firefox), which both say 'X is not defined'. That points to the error actually occurring inside the native Breeze Viewer desktop app's embedded WebView, not the poster's browser tab. apps/viewer/src-tauri/Cargo.lock confirms the Linux build of that Tauri app links webkit2gtk (with javascriptcore-rs as its JS engine) — this is the WebView Tauri uses on Linux (an AppImage per the docs' Viewer Installers table). Depending on the distro's webkit2gtk/GStreamer build, RTCPeerConnection can be entirely absent as a global, so WebRTC can never start. The code does catch this and returns null so DesktopViewer.tsx's connect() (lines 913-919) falls back to the WebSocket/JPEG transport, but nothing detects/warns about missing WebRTC support up front, and there's no documentation of this Linux WebView limitation. The user's cross-platform pattern (Windows+Chrome/WebView2 works, Debian+Firefox/Chrome via the same native Viewer app fails) is consistent with this being a WebView-engine gap on Linux rather than a TURN/network issue.Affected code
apps/viewer/src/lib/webrtc.ts:101— new RTCPeerConnection(...) called with no feature-detection guardapps/viewer/src/lib/transports/webrtc.ts:186-201— catch block logs 'WebRTC connection failed:' + err — matches the reported console line verbatim, and swallows non-Agent/SessionEnded errors, returning nullapps/viewer/src/components/DesktopViewer.tsx:913-919— connect() falls back to connectWebSocket only after webrtcOk is falsy, i.e. after this exact ReferenceError is caughtapps/viewer/src-tauri/Cargo.lock:5302-5324— webkit2gtk (+ javascriptcore-rs) is a dependency of the Linux Viewer build — the WebView/engine that produces 'Can't find variable' style ReferenceErrorsPotential fix
Feature-detect RTCPeerConnection before calling createWebRTCSession (e.g.
if (typeof RTCPeerConnection === 'undefined') return nullearly in webrtc.ts) so the viewer skips straight to the WebSocket fallback with a clear log/UI hint ('WebRTC unsupported on this system, using WebSocket fallback') instead of relying on catching a ReferenceError, and document the webkit2gtk/GStreamer WebRTC dependency for the Linux AppImage build.Triage analysis, affected code, and fix sketch above were produced by automated investigation (@breeze-discord). Verify before relying on them.