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 26939 - Information returned on MediaStreamTrack ended event
Summary: Information returned on MediaStreamTrack ended event
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Dominique Hazael-Massieux
QA Contact:
Depends on:
Reported: 2014-09-30 09:20 UTC by Harald Alvestrand
Modified: 2014-11-11 14:47 UTC (History)
5 users (show)

See Also:


Description Harald Alvestrand 2014-09-30 09:20:53 UTC
From mailing list on Aug 29:

How do I get information about what happened to a MediaStreamTrack when it's ended?

What we currently have is an event handler of type "ended", which uses the Event interface, which, as defined in has the interface:

<<copy deleted>>

The "type" field is set to "ended" if I understand the spec correctly.

We COULD get information back in a way that's consistent with other interfaces if we did two changes:

- Declare the type of interface for "ended" to be MediaStreamErrorEvent
- Declare the "error" attribute of the MediaStreamErrorEvent to be nullable (for the case where there is no error)

We could also make a new event type with a different interface than MediaStreamErrorEvent, or do something entirely different - but not offering any way to differentiate between "the track ended because the user called stop() on it" and "the track ended because the driver crashed and there's memory corruption in the buffers" seems like a non-optimal situation.
Comment 1 Jan-Ivar Bruaroey [:jib] 2014-09-30 15:23:02 UTC
Firstly, people should not operate WebRTC while driving.

I don't have a strong preference, but if we're going to use events to report success/failure, then overloading MediaStreamErrorEvent to make it fireable without an error seems useful. It also shouldn't be a problem in practice (it's not like listeners to the related 'onoverconstrained' are going to need to check for null all of a sudden).

I hate to say it, but the 'ended' attribute would actually have made for a great promise! E.g.

  pc.ended.then(() => log("Ended!")), err => log("Dropped! " + err));
Comment 2 Jan-Ivar Bruaroey [:jib] 2014-09-30 16:06:40 UTC
uh, if a track was named 'pc'. Trying again:

  track.ended.then(() => log("Ended!")), err => log("Terminated! " + err));
Comment 3 Stefan Hakansson LK 2014-10-30 16:53:44 UTC
Discussed at the f2f Oct 30 2014. J-I presented a proposal to use an ended Promise, but the consensus ended up with stick with only the ended event, but add error info to the event.
Comment 4 Anne 2014-10-30 17:11:58 UTC
Was there any rationale presented to not go with a promise? Seems like a perfect place to use a promise.
Comment 5 Domenic Denicola 2014-10-30 17:23:51 UTC
The argument against promises was with consistency with other state transition events.

However, both a promise (since it's a better fit than events for this kind of thing) and an event (for consistency) seems feasible?
Comment 6 Dominique Hazael-Massieux 2014-11-04 15:43:28 UTC
Proposed edit that reuses MediaStreamErrorEvent: as discussed at the F2F
Comment 7 Stefan Hakansson LK 2014-11-11 14:47:17 UTC
The PR (#50) has been incorporated now, and as far as I can tell it fixes this bug.

Closing the bug.