| Summary: | MediaStreamTrack endedEvent fired when RTCPeerConnection connectionState is already RTCPeerConnectionState::Closed | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Gabriel Nava Marino <gnavamarino> |
| Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | webkit-bug-importer, youennf |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Gabriel Nava Marino
2022-01-12 17:11:07 PST
I think all browsers do fire ended events. I am guessing we should either update the spec or implementations. Ah, nevermind, browsers do fire events when close is called. I think they do not when their context goes away as the dom object would be stopped. It would be good to validate that other browsers are not firing such events in case of GCing the peer connection. Per Youenn's recommendation in the related radar: We should probably update MediaStreamTrack::trackEnded to queue a task to fire the event instead of firing the event right away. This matches https://w3c.github.io/mediacapture-main/#track-ended. This would allow to remove the activeDOMObjectsAreSuspended/activeDOMObjectsAreStopped checks in that method. It would also be good to write a corresponding test. internals.simulateMediaStreamTrackCaptureSourceFailure maybe be able to help validate that the event is not fired synchronously. Will implement "queue a task to fire ended event" in bug 235227. |