This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24930 - the spec defines the removetrack event as part of the MediaStream interface, but never calls out when the event should be fired
Summary: the spec defines the removetrack event as part of the MediaStream interface, ...
Status: RESOLVED FIXED
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: public-media-capture@w3.org
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-04 22:55 UTC by Shijun Sun
Modified: 2014-05-08 14:16 UTC (History)
3 users (show)

See Also:


Attachments

Description Shijun Sun 2014-03-04 22:55:16 UTC
The Media Capture and Streams spec defines the removetrack event as part of the MediaStream interface, but never calls out when the event should be fired.

Propose to change the following in Section 4.2.3

When the removeTrack() method is invoked, the user agent MUST run the following steps:
1. Let track be the MediaStreamTrack argument and stream this MediaStream object.
2. If stream is finished, throw an INVALID_STATE_ERR exception.
3. If track is in stream's track set, remove it.

to the following:

When the removeTrack() method is invoked, the user agent MUST run the following steps:
1. Let track be the MediaStreamTrack argument and stream this MediaStream object.
2. If track is ended, throw an INVALID_STATE_ERR exception.
3. If track is not in stream's track set, then abort these steps.
4. If track is in stream's track set, remove it, and then queue a task to fire a removetrack event.

Note: a missing step (#3) is also added and a couple typos in step #2 are fixed.
Comment 1 Adam Bergkvist 2014-03-05 14:03:13 UTC
You're right about the (incorrect) state check on MediaStream before a new track is added. It's old language from the time when MediaStream could be ended. Now a MediaStream is active or inactive and new tracks can be added to an inactive stream to make it active again.

Checking the state of the MediaStreamTrack being added is a new thing, but I think it's correct to do so.
Comment 2 Stefan Hakansson LK 2014-05-08 09:21:14 UTC
Seems to be fixed in version http://dev.w3.org/2011/webrtc/editor/archives/20140507/getusermedia.html (according to the change log it was fixed in an earlier version).

Do you agree Shijun?
Comment 3 Shijun Sun 2014-05-08 14:16:18 UTC
The spec defines a MediaStreamTrackEvent for both removetrack and addtrack. So, it is okay to say the bug is fixed.

The MediaStreamTrackEvent section (4.4) still has a couple TODO's.  I hope there is a bug to track the open issues there already.