2007284 - Camera indicator light remains on after stopping getUserMedia video track when permission is granted before preview finishes (macOS, Firefox)

Status: RESOLVED FIXED

(Firefox :: Site Permissions, defect, P2)

Description

[leon wei]

Attachment: firefox-demo.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36

Steps to reproduce:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0

1. On macOS, open Firefox (tested on Firefox 145 / 146 / 147).
2. Open a webpage that calls getUserMedia({ video: true }).
3. Trigger getUserMedia() (e.g. by clicking a button).
4. When the Firefox camera permission dialog appears:, Immediately click “Allow” before the permission dialog preview video finishes loading.
5. stop all tracks: ( stream.getTracks().forEach(track => track.stop()); )

Actual results:

MediaStreamTrack.readyState becomes to "ended", but the macOS camera indicator light remains on indefinitely unless try capture audio stream or close Firefox .

I was unable to reproduce on window Firefox.

Expected results:

After calling MediaStreamTrack.stop() on all tracks， the macOS camera indicator light turns off.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Audio/Video' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[leon wei]

Attachment: Screenshot2025_12_21_125121.png

add the preview screenshot img

Comment 3

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jib, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Karl Tomlinson (:karlt)]

I saw this with a slightly different test file that set enabled to false on the content track immediately after the gUM stream promise resolved.
The CamerasChild::StartCapture() in the parent process capture was called after CamerasChild::StopCapture() in the content process.
https://pernos.co/debug/fqkQzdNz0HfRDs-AQgq-lg/index.html

Comment 5

[Karl Tomlinson (:karlt)]

The code to prevent the preview was removed at https://hg-edge.mozilla.org/mozilla-central/rev/54a9e7679269#l1.21 and
https://hg-edge.mozilla.org/mozilla-central/rev/54a9e7679269#l1.151 and no replacement mechanism was provided.

The disconnectedCallback() won't stop the preview if it hasn't started yet.

Comment 6

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 799415

Comment 7

[Emma Zühlcke [:emz]]

It was a bit tricky to reproduce, but if I add a setTimeout call here https://searchfox.org/firefox-main/rev/33bba5cfe4a89dda0ee07fa9fbac578353713fd3/browser/components/webrtc/content/webrtc-preview/webrtc-preview.mjs#109 I can see the issue.

Comment 8

[Emma Zühlcke [:emz]]

Attachment: Bug 2007284 - Properly clean up webrtc previw video stream when preview is closed while loading. r=jib,karlt

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/022c942d4079
https://hg.mozilla.org/integration/autoland/rev/68583bf964c8
Properly clean up webrtc previw video stream when preview is closed while loading. r=karlt

Comment 10

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/68583bf964c8

Comment 11

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:emz, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox147 to wontfix.

For more information, please visit BugBot documentation.

Comment 12

[Simona Badau, Desktop Test Engineering]

Tried to reproduce the initial issue using Firefox 147 (Build ID: 20260105210555) and Nightly 148.0a1 (Build ID: 20260106212859) on macOS 15, but was unable to reproduce it. On my MacBook Pro, the camera indicator light turns off as expected on the affected Firefox versions.

@leon wei, could you please verify whether the issue is still reproducible on your end when using Firefox 148 Beta?