26939 2014-09-30 09:20:53 +0000 Information returned on MediaStreamTrack ended event 2014-11-11 14:47:17 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified PC Linux RESOLVED FIXED P2 normal --- 1 harald dom annevk d jib public-media-capture stefan.lk.hakansson oldest_to_newest 112450 0 harald 2014-09-30 09:20:53 +0000 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 http://www.w3.org/TR/dom/#events 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. 112469 1 jib 2014-09-30 15:23:02 +0000 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)); 112474 2 jib 2014-09-30 16:06:40 +0000 uh, if a track was named 'pc'. Trying again: track.ended.then(() => log("Ended!")), err => log("Terminated! " + err)); 114247 3 stefan.lk.hakansson 2014-10-30 16:53:44 +0000 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. 114251 4 annevk 2014-10-30 17:11:58 +0000 Was there any rationale presented to not go with a promise? Seems like a perfect place to use a promise. 114253 5 d 2014-10-30 17:23:51 +0000 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? 114493 6 dom 2014-11-04 15:43:28 +0000 Proposed edit that reuses MediaStreamErrorEvent: https://github.com/w3c/mediacapture-main/pull/50 as discussed at the F2F 114799 7 stefan.lk.hakansson 2014-11-11 14:47:17 +0000 The PR (#50) has been incorporated now, and as far as I can tell it fixes this bug. Closing the bug.