Repository navigation
stereo camera: the runtime consent prompt races Chromium's 10 s capture-start timeout (AbortError) #1842
Description
Found during the SR-laptop hardware check of runtime #1838 + browser-pvt #245 (2026-10-06).
When the runtime has to show its consent prompt for a browser (no stored decision and no delegation, e.g. a browser started with an auto-grant/automation switch, so it declines delegation, or any unregistered browser), the user effectively has 10 seconds to answer: Chromium's video capture start times out after a fixed 10 s (AbortError: Timeout starting video source), while the runtime's tray prompt waits up to 60 s. Observed: service REFUSED … the consent prompt was not answered (delegation not applied: the client declined delegation), page AbortError (not NotAllowedError).
Options:
- Runtime: answer
xrStartStereoCameraStreamDXRwith a distinct pending result fast (e.g.XR_STEREO_CAMERA_CONSENT_PENDING) and let the client retry, so the capture start never blocks on a human. - Browser (B1): start the device without waiting on the runtime's stream start (deliver a first black frame / hold the track) and surface consent refusal as
NotAllowedErrorwhen the answer arrives. - Shorter runtime prompt timeout for browser clients (just moves the race).
(1)+(2) is the robust fix; until then the prompt is only usable if answered quickly.
Activity
dfattal commentedon Oct 7, 2026
Fix in progress, browser-side (David: fix + merge + release when green): the B1 capture path raises Chromium's video-capture start timeout to 75 s for the DisplayXR 3D Camera device only (> the runtime's 60 s PROMPT_TIMEOUT_MS), so the user can answer the tray prompt; every other camera keeps Chromium's default. Lands on browser-pvt #245. No runtime change needed for this; a runtime-side CONSENT_PENDING result stays a possible later refinement.
dfattal commentedon Oct 7, 2026
Verified on the SR laptop (runtime v2.28.0 + Leia v2.11.0 + browser-pvt #245 d7b6c35): unanswered prompt → refused at exactly 60 s → page gets NotAllowedError (not AbortError at 10 s); Allow clicked ~17 s after the start → frames. Fixed by browser-pvt #245 (3D Camera capture start timeout 75 s).
One small runtime follow-up seen in the first run: the prompt timed out at 60.0 s (REFUSED, 'not answered'), yet an Allow was stored for that exe afterwards — an answer clicked after the timeout is still persisted. Either close/disable the tray dialog when the timeout fires, or drop a late answer instead of storing it.
fix(stereo-camera): a consent answer after the prompt timed out is dr…
dfattal commentedon Oct 15, 2026
Closing: the remaining follow-up (an answer clicked after the 60 s timeout was still stored) was fixed by #1844 (edce9d9), shipped in v2.30.0. A late, double or stale answer is now dropped and never reaches the store, and the dialog is closed when its request ends. The 10 s race itself was fixed browser-side in browser-pvt #245.