New issue
Advanced search Search tips
This site will be read-only for 3-4 hours starting at Sunday, 08:00AM PDT
Starred by 3 users

Issue metadata

Status: WontFix
Closed: Jan 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

Sign in to add a comment

MediaStreamTrack::stop() can break unrelated WebRTC streams

Reported by, Dec 16 2016 Back to list

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce the problem:
1. Run test.html (hosted on HTTPS server)
2. Click "Restart vid2" button THREE times

What is the expected behavior?
The Vid2 frame restarts a third time.

What went wrong?
1. The Vid2 frame can't restart again
2. The Vid1 frame stalls (breaks) even though it is entirely unrelated and has not been touched by the "Restart vid2" onclick handler.
3. WebRTC appears to be totally broken after this point

Did this work before? Yes Not certain but I believe it worked correctly in the previous Chrome release

Does this work in other browsers? Yes

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0

Commenting out the line:


Will avoid the problem. It appears that MediaStreamTrack::stop() is the culprit.
1.3 KB View Download

Comment 1 by, Dec 16 2016

Repro'ed on both Mac and Windows. Worked fine in previous versions of Chrome and still works fine in Firefox.
Status: Assigned

Comment 3 by, Dec 16 2016

might be an URL.createObjectURL issue, which uses srcObject works fine here.
Here is quick test page of the original report: I can reproduce the problem in M55+. However, it seems to work for me in 54.0.2840.0. miu@ this looks like related to [0]. Commenting out the update consumer lines on [1] fixes it.

Comment 6 by, Dec 16 2016

FWIW I'm still able to repro using srcObject instead of src. However, it only repro's if I set srcObject to null again before calling stop() :

Comment 7 by, Jan 10 2017

Status: WontFix
Just tested in 56.0.2924.51 (Official Build) beta (64-bit), and it seems to be working correctly. Must've been a bug that got fixed somewhere along the way. If so, the fix will go out in just a week or two (with Chrome 56 stable).

Feel free to re-open if you see a recent beta, dev, or canary channel build still has the problem.

Sign in to add a comment