All users were logged out of Bugzilla on October 13th, 2018

GetUserMedia MediaStream.stop() should no longer be used but is still required to get rid of permission indicator after stopping all local tracks

RESOLVED FIXED in Firefox 44

Status

()

P1
normal
Rank:
18
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: longsleep, Assigned: pehrsons)

Tracking

Trunk
mozilla44
Points:
---

Firefox Tracking Flags

(firefox44 fixed)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.15 Safari/537.36

Steps to reproduce:

Capture a local media device with getUserMedia and stop all the tracks. 


Actual results:

The devices get disabled but the media capture permission indicator stays visible.


Expected results:

MediaStream.stop() is deprecated and instead one should use the stop() function on the tracks. While the camera and mic gets stopped fine when stopping the corresponding tracks, the permission indicator for the audio and/or video capture permissions stays until MediaStream.stop() is called. In the getUserMedia case the stream implementes the LocalMediaStream prototype which still seems to have a stop() function to exactly do this.

LocalMediaStream needs to go away and the behavior should be added to MediaStreamTrack.stop() so that the code example below does also remove the permission indicator.


navigator.getUserMedia({audio: false, video: true},
    function(stream) {
         // can also use getAudioTracks() or getVideoTracks()
        var track = stream.getTracks()[0];  // if only one media track
        // ...
        track.stop();
    },
    function(error){
        console.log('getUserMedia() error', error);
    });


This happens with current stable (39) and also with current nightly (42),

Workaround is to call the stop() function on the LocalMediaStream in addition to stopping the tracks.
(Reporter)

Comment 1

3 years ago
Added a simple fiddle to reproduce - run it here: https://jsfiddle.net/efzss9fc/

var p = navigator.mediaDevices.getUserMedia({audio: false, video: true});

p.then(function(stream) {
    console.log("stream", stream);
    var track = stream.getTracks()[0]; 
    console.log("track", track);
    track.stop();
});

p.catch(function(e) { console.log(e.name); });
(Reporter)

Updated

3 years ago

Updated

3 years ago
Component: Untriaged → Device Permissions
Version: 39 Branch → Trunk
I don't think this is a front-end issue; or at least I think there's something to do in the back-end to get this fixed, as there's likely a missing notification, or mediaCaptureWindowState not returning the right value.
Component: Device Permissions → WebRTC: Audio/Video
Product: Firefox → Core

Updated

3 years ago
Status: UNCONFIRMED → NEW
backlog: --- → webrtc/webaudio+
Rank: 18
Ever confirmed: true
Priority: -- → P1
(Assignee)

Comment 3

3 years ago
This is because the ending of our internal gUM stream triggers removal of the sharing indicator.

The spec doesn't have ending streams anymore, just ending tracks (streams are now active/inactive depending on whether they have any non-ended tracks).

Before we get to fixing this in our stack we can just fix the indicator by removing it when all tracks in a given `GetUserMediaCallbackMediaStreamListener` have stopped.
Assignee: nobody → pehrsons
Status: NEW → ASSIGNED
(Assignee)

Comment 4

3 years ago
Created attachment 8665239 [details]
MozReview Request: Bug 1192170 - Remove media capture indicator when all tracks have ended. r?jib

Bug 1192170 - Remove media capture indicator when all tracks have ended. r?jib
Attachment #8665239 - Flags: review?(jib)
Comment on attachment 8665239 [details]
MozReview Request: Bug 1192170 - Remove media capture indicator when all tracks have ended. r?jib

https://reviewboard.mozilla.org/r/20173/#review18101

lgtm.

::: dom/media/MediaManager.h:183
(Diff revision 1)
> +           !mVideoDevice->GetSource()->IsAvailable() &&
>             mVideoDevice->GetMediaSource() == dom::MediaSourceEnum::Camera &&

Do we want to check dom::MediaSourceEnum::Camera first, or do all sources support IsAvailable()?
Attachment #8665239 - Flags: review?(jib) → review+
(Assignee)

Comment 6

3 years ago
https://reviewboard.mozilla.org/r/20173/#review18101

> Do we want to check dom::MediaSourceEnum::Camera first, or do all sources support IsAvailable()?

All sources do, and we're already checking `IsAvailable()` for the others in `CapturingScreen/Window/Application/Browser`.
https://hg.mozilla.org/mozilla-central/rev/d6f8dd472649
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Some clarification on STRs for this bug. It seems to depend on the order the tracks are closed in.

Closing them in reverse order leaves the light on, while closing them in regular forEach order seems to work: http://jsfiddle.net/jib1/eq9z0d0h/
This might be worth uplifting.
(Assignee)

Comment 13

3 years ago
(In reply to Jan-Ivar Bruaroey [:jib] from comment #10)
> Some clarification on STRs for this bug. It seems to depend on the order the
> tracks are closed in.
> 
> Closing them in reverse order leaves the light on, while closing them in
> regular forEach order seems to work: http://jsfiddle.net/jib1/eq9z0d0h/

No, that's not it. Here, I fixed your fiddle: http://jsfiddle.net/eq9z0d0h/5/

(audio was false, so tracks[1] was undefined)
(Assignee)

Comment 14

3 years ago
(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #13)
> No, that's not it. Here, I fixed your fiddle: http://jsfiddle.net/eq9z0d0h/5/
> 
> (audio was false, so tracks[1] was undefined)

And with that I think I confused myself by looking at the camera LED rather than the in-Firefox indicator. Sorry, you're right jib!
(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #13)
> (audio was false, so tracks[1] was undefined)

Ugh, yeah sorry about the confusion.

Ah, so the camera light is fine, it was just the Firefox camera indicator that was wrong.
You need to log in before you can comment on or make changes to this bug.