engineering/zebra-report
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
zebra-report/docs/tickets/0002-fedora-firefox-cannot-share-camera.md
Russell Ballestrini e321a7cee1
docs: add tickets dir + first two open defects 
zebra-report didn't have a defect tracker before; until now everything
lived in commit-message archaeology and signal-server log greps. Two
known defects make this the right moment to start one:

  0001: fedora chrome cannot hear speakers (P0, in-progress)
    P0 because every invariant (RTP arriving, worklet started,
    ctxState=running) is green but the user hears nothing — silent
    regression is trust-eroding. Primary hypothesis is that
    AudioContext.destination always routed to system-default while
    the speaker-output picker only setSinkId'd <audio> elements.
    Fix landed in 467146a (applySinkToAudioCtx), awaiting fox retest
    in production.

  0002: fedora firefox cannot share camera (High, open)
    Camera publish fails on firefox; chrome same machine works.
    No telemetry yet; ticket enumerates the candidates to narrow
    on the next attempt.

README.md spells out the format (status / priority / surface / first
seen, then symptom / telemetry / hypothesis / fix / status notes)
and the resolution loop (telemetry → failing test → fix → stamp →
deploy → update ticket).
2026-06-07 11:24:17 -04:00

2.7 KiB
Raw Blame History

0002: fedora firefox cannot share camera

Status: open Priority: High (feature unavailable — speakers expect to share camera) Surface: fedora firefox — speaker or host attempting to publish camera First seen: 2026-06-06 Reporter: fox

Symptom

On fedora firefox, the "share camera" button does not result in a camera publish. Same firefox can share screen and publish mic — only camera publish fails. Same machine + chrome publishes camera fine.

Telemetry / Repro

Not yet captured.

Repro candidates to try:

  1. Open fedora firefox → enter a room as speaker
  2. Click "share camera"
  3. Note whether the browser permission prompt appears
  4. If granted, note whether the camera tile renders locally
  5. Grab the in-page signal log + browser console output

Things to specifically look for:

  • getUserMedia errors (NotFoundError, NotReadableError, OverconstrainedError, NotAllowedError)
  • Whether navigator.mediaDevices.enumerateDevices() lists the camera pre-permission (label is empty, deviceId present)
  • Whether the camera deviceId saved in localStorage (CAM_DEV_KEY) matches a device firefox still recognizes (deviceIds rotate across sessions on chrome but should be stable on firefox)

Hypothesis

Candidates, none yet confirmed:

  1. Saved cameraDeviceId pointing at a stale / removed device. Firefox would OverconstrainedError and the page's catch logs err. Fix would be: on OverconstrainedError, retry with deviceId unset and re-prompt the picker — same shape as the mic-label-fallback at line ~5041.

  2. Firefox v4l2 backend conflicting with chrome's hold on the camera. If chrome was using the camera, firefox can't open it (single-consumer on most fedora kernels). User-visible workaround: close chrome's camera-using tab.

  3. Firefox MediaTrackConstraints quirk — possibly the page's videoConstraints (line ~4493) demanding a resolution / framerate the camera doesn't support → OverconstrainedError. Fix: relax the constraints to { ideal } for non-essential fields.

  4. Permission state stuck. Firefox's permission prompt is gated per origin + device; a previous "block" decision can persist. about:permissions would show this. Not a code issue if so.

  5. PipeWire / v4l2loopback fakery on the system — if the camera device is actually a virtual capture (OBS Virtual Cam etc), firefox may reject it where chrome accepts.

Fix

(none yet — needs telemetry)

Status notes

  • 2026-06-07 (open): ticket created. Next step is to capture the firefox console / signal log when the share-camera button is clicked and see which of the hypotheses fits.