You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the WebRTC GStreamer plugins loading correctly (see #3494)
and a working audio input device present, starting a huddle on Linux fails with:
The request is not allowed by the user agent or the platform in the current
context, possibly because the user denied permission.
No permission prompt is ever shown.
On macOS/Windows the OS provides the mic-permission UI, but on Linux WebKitGTK the embedding application must answer WebKitUserMediaPermissionRequest (via the permission-request signal / wry's permission hook) — an unanswered request is a
denial. I can't find a handler for this in the desktop shell, which would make getUserMedia structurally un-grantable on Linux regardless of hardware.
Diagnostic ladder ruled out (Arch, native 0.5.0):
GStreamer webrtc/nice plugins load (after the bundled-lib workaround above);
an audio source is present and enumerable (verified with a PipeWire source;
with no source present the error is a constraint error instead, as expected);
the failure is then NotAllowedError with no prompt → permission layer.
Suggested fix: handle WebKitUserMediaPermissionRequest in the Linux WebView
(allow for the app's own origin, or surface an in-app prompt), and ideally also webkit_settings_set_enable_media_stream(TRUE) if not already set.
Happy to test a build — this is the last blocker for voice on native Linux as far
as I can tell.
Confirmed fixed by #3607 on 0.5.3 (Arch Linux, native extracted install) — huddles now open and work end-to-end, including voice conversation with an agent.
One note for anyone testing on non-Debian distros: #3494 (bundled libsoup-3.0/libnghttp2 shadowing system libs) still applies on 0.5.3 — without the rename workaround the system GStreamer WebRTC plugins don't load, so huddles fail for a different reason before this fix is even reachable.
Activity
dekanbro commentedon Jul 29, 2026
Confirmed on a second Linux distribution with the same failure.
Environment:
Behavior:
Local diagnostics:
pulsesrc,pipewiresrc, andautoaudiosrcplugins are available.This matches the unhandled WebKitGTK user-media permission-request diagnosis and shows the problem is not Arch-specific.
wpfleger96 commentedon Jul 30, 2026
fixed in #3607
scottsanpedro commentedon Jul 31, 2026
Confirmed fixed by #3607 on 0.5.3 (Arch Linux, native extracted install) — huddles now open and work end-to-end, including voice conversation with an agent.
One note for anyone testing on non-Debian distros: #3494 (bundled libsoup-3.0/libnghttp2 shadowing system libs) still applies on 0.5.3 — without the rename workaround the system GStreamer WebRTC plugins don't load, so huddles fail for a different reason before this fix is even reachable.