This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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));
uh, if a track was named 'pc'. Trying again: track.ended.then(() => log("Ended!")), err => log("Terminated! " + err));
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.
Was there any rationale presented to not go with a promise? Seems like a perfect place to use a promise.
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?
Proposed edit that reuses MediaStreamErrorEvent: https://github.com/w3c/mediacapture-main/pull/50 as discussed at the F2F
The PR (#50) has been incorporated now, and as far as I can tell it fixes this bug. Closing the bug.