Skip to content

Linux: huddles fail with NotAllowedError — WebKitGTK user-media permission request appears unhandled #3495

Closed

Description

@scottsanpedro

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):

  1. GStreamer webrtc/nice plugins load (after the bundled-lib workaround above);
  2. 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);
  3. 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.

Environment: as #3494.

Activity

  1. dekanbro commented on Jul 29, 2026

    @dekanbro

    Confirmed on a second Linux distribution with the same failure.

    Environment:

    • Ubuntu 24.04 (Noble), GNOME Wayland
    • Buzz Desktop 0.5.0 native build
    • PipeWire 1.0.5; pipewire, pipewire-pulse, and WirePlumber all active

    Behavior:

    1. Starting a huddle creates the huddle lifecycle entry.
    2. It immediately rolls back to Huddle · Ended — 1 participant.
    3. No microphone permission prompt is shown.
    4. The UI reports: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.

    Local diagnostics:

    • PipeWire sees Buzz playback routed to the active speaker.
    • A working internal digital microphone is present and selected as the live default source.
    • GStreamer pulsesrc, pipewiresrc, and autoaudiosrc plugins are available.
    • No Buzz microphone capture stream appears when the huddle attempt fails.

    This matches the unhandled WebKitGTK user-media permission-request diagnosis and shows the problem is not Arch-specific.

  2. wpfleger96 commented on Jul 30, 2026

    @wpfleger96
    Member

    fixed in #3607

  3. scottsanpedro commented on Jul 31, 2026

    @scottsanpedro
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions