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

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect, P1)

Description

[Simon Eisenmann]

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.

Comment 1

[Simon Eisenmann]

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); });

Comment 2

[Florian Quèze [:florian]]

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.

Comment 3

[Andreas Pehrson [:pehrsons]]

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.

Comment 4

[Andreas Pehrson [:pehrsons]]

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

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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()?

Comment 6

[Andreas Pehrson [:pehrsons]]

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`.

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d6f8dd472649

Comment 8

[Andreas Pehrson [:pehrsons]]

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=94d3ed4c4e4b

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d6f8dd472649

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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/

Comment 11

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

s/close/stop/

Comment 12

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

This might be worth uplifting.

Comment 13

[Andreas Pehrson [:pehrsons]]

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

Comment 14

[Andreas Pehrson [:pehrsons]]

(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!

Comment 15

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(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.

Comment 16

[Zac Spitzer]

https://nimiq.github.io/qr-scanner/demo/

this isn't working in nightly 71.0a1 (2019-09-25) (64-bit) or 69.0.1 (64-bit) on Win10

the red video indicator stays on if you type in the console

document.getElementById('qr-video').srcObject.getTracks()[0].stop()

Comment 17

[Andreas Pehrson [:pehrsons]]

(In reply to Zac Spitzer from comment #16)

https://nimiq.github.io/qr-scanner/demo/

this isn't working in nightly 71.0a1 (2019-09-25) (64-bit) or 69.0.1 (64-bit) on Win10

the red video indicator stays on if you type in the console

document.getElementById('qr-video').srcObject.getTracks()[0].stop()

See bug 1568169.