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 24928 - the spec defines the addtrack event as part of the MediaStream interface, but never calls out when the event should be fired.
Summary: the spec defines the addtrack event as part of the MediaStream interface, but...
Status: RESOLVED WONTFIX
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:52 UTC by Shijun Sun
Modified: 2014-04-04 07:31 UTC (History)
2 users (show)

See Also:

Attachments

Description Shijun Sun 2014-03-04 22:52:40 UTC 
The Media Capture and Streams spec defines the addtrack 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 addTrack() 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 already in stream's track set, then abort these steps.
4. Add track to stream's track set.
 
to the following:
 
When the addTrack() 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 already in stream's track set, then abort these steps. 
4. Add track to stream's track set, then queue a task to fire an addtrack event.
 
Note: this will also fix a couple typos in step #2, i.e. from "stream is finished" to "track is ended".
Comment 1 Adam Bergkvist 2014-03-05 13:52:29 UTC 
Hi and thanks for providing feedback on the spec.

The question whether the "addtrack" event should be fired as a result of MediaStreamTrack.addTrack() has been brought up a few times before.

The event is intended to asynchronously notify the script that the platform has updated the stream's track set. The new track is added to the track set as the event is dispatched. Direct manipulation with addTrack() doesn't need the event since the new track is added synchronously; i.e. you can, e.g., read out the new track set length on the next line of code. Having the event could on the other hand complicate things since by the time the event is dispatched, the track could have been removed already.

The question is if the definition of the event should be in this spec or if it should be defined where it's actually used.
Comment 2 Shijun Sun 2014-03-07 00:10:22 UTC 
It seems okay to remove the addtrack event from the spec as long as the addtrack() call is synchronous.  Same to the removetrack event (as mentioned in bug 24930).
Comment 3 Adam Bergkvist 2014-03-07 09:33:45 UTC 
But your comment regarding the stream state check is still valid. That needs to be fixed.

I noted that the MediaStrem() constructor, which takes an other MediaStream or a sequence of MediaStreamTracks, ignores ended tracks when constructing the track set of the new stream. Should we do the same here or throw? I think it's could be motivated to throw for addTrack() since you're only adding a single track. The ignore-approach for the constructor acts like a filter for ended tracks since several tracks can be added at once.
Comment 4 Shijun Sun 2014-03-07 17:15:13 UTC 
Agree, "throw" is more intuitive for addTrack(), but not so for the MediaStream() constructor.