- From: Eric Carlson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 May 2021 21:16:10 +0000
- To: public-webrtc-logs@w3.org
> I ran a test with Firefox, Safari and Chrome to see how they're handling this nowadays. > > The test consists in the following steps: > > 1. Assign a MediaStream with an audio track and no video track to a video element. > 2. Add a video track to the MediaStream assigned in step 1. > 3. Remove the video track from the MediaStream assigned in step 1. > 4. Add the same video track again to the MediaStream assigned in step 1. > > Firefox and Chrome behave the same. They don't run the full load algorithm and fire the "resize", "canplay" and "playing" events on step 2. They don't fire any events on step 3 and 4. If the track added in step 4 has a different size, "resize" is fired. > This seems wrong. The media element spec says the ['resize' event should be fired](https://html.spec.whatwg.org/#concept-video-intrinsic-width): > Whenever the intrinsic width or intrinsic height of the video changes (including, for example, because the selected video track was changed) ... I would think that "the selected video track was changed" includes removing an active video track. > Safari fires ... fires "resize", "loadedmetadata" and "canplay" again on step 4. I guess the reason for the resize events in step 3 and 4 for Safari is that it internally changes the size on track removal while Chrome and Firefox do not. > Removing the video track shouldn't cause the readyState to drop below HAVE_METADATA, so firing 'loadedmetadata' and 'canplay' also seems wrong. I filed https://bugs.webkit.org/show_bug.cgi?id=225612 to investigate this. -- GitHub Notification of comment by eric-carlson Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/453#issuecomment-837355985 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 May 2021 21:16:12 UTC