Deprecated stream.stop() is JS-observably slow at stopping gUM compared to track.stop()

NEW
Unassigned

Status

()

Core
WebRTC: Audio/Video
P4
normal
Rank:
35
a year ago
a month ago

People

(Reporter: jib, Unassigned)

Tracking

50 Branch
Unspecified
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

STR (in 50+):
1. Open http://jsfiddle.net/oqaofdxq/
2. Share Selected Device.
3. Repeat 4 times (by Hitting "Run" and share again)

Expected output:
- gUM is off

Actual output (most of the time):
- gUM is on

Workaround 1:
- Uncomment stream.getTracks()[0].stop(); instead of stream.stop();

Workaround 2:
- Add a .then(() => new Promise(r => setTimeout(r, 100)) before .then(haveGum)


I don't see any way for JS to exploit this, but it's racy JS-observable behavior we should probably avoid, and it makes writing certain tests ugly, so if there's an easy fix that would be great.
Is "MediaStream.stop is old and deprecated, don't use it" not enough?

In all fairness it's from a time when we didn't have MediaStreamTrack.stop so they shouldn't really be mixed.

I don't think there's an easy fix because a MediaStream from gUM doesn't track all its tracks' clones, which would also have to be stopped.
Rank: 35
Priority: -- → P3
I suspect it will be with us for a while, given that Chrome has yet to pivot to tracks, so we may want to fix JS observable behavior. Not a big deal I agree, as long as we're ok with removing excess uses in our tests (except one I suppose). I filed it in case it was easy to fix.
Well, they haven't for RTCPeerConnection, but they seem ok from getUserMedia. At least Chrome 52 doesn't have MediaStream.stop().
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.