- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Dec 2024 10:00:07 +0000
- To: public-webrtc-logs@w3.org
> it must block frames on main thread. Sure, the question is about blocking for more than the current task, i.e. during a time that the web app is controlling. > It's not a state as far as the web developer is concerned, merely a delay function. It is a state if we introduce asynchronous pausing controlled by the web page. This seems redundant with `track.enabled`. > Fuzzing might be needed if two websites capture the same window (or different tabs of the same browser window) at the same time. Otherwise the user might be correlated across origins when they resize the window. In this particular case, user decided to switch one of the source, not the other. So the `configurationchange` event will only be received by one of the page. No fuzzing needed at all. In general though, the fuzzing is not protecting the user since the two windows can easily correlate the user with the media content itself. This is the big difference with fuzzing `devicechange` for instance. I think we added the note to be extra careful, we should probably think of removing it. > > Updating the settings before the callback makes sense to me, ... > > Can you elaborate on why that makes sense to you? Having the old settings is a potential footgun and would probably come as a surprise to web developers. It would for instance be nice to know that the capture is switching from a window to a screen, the web app might want to pause the sending of the video and display some warning to the user in this case. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/15#issuecomment-2531069686 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 10 December 2024 10:00:08 UTC