- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 09 Dec 2024 22:24:03 +0000
- To: public-webrtc-logs@w3.org
> The fuzzing note is related to device label change, ... A track's [label](https://www.w3.org/TR/mediacapture-streams/#dom-mediastreamtrack-label) is neither dynamic nor part of the [_"track's capabilities and settings"_ ](https://w3c.github.io/mediacapture-extensions/#change-track-configuration). AFAIK this event exists for downstream sinks to adapt their consumption of the track to its evolved properties (e.g. new dimensions or skip applying blur). The event won't even fire when users switch capture between tabs in the same window, because the configuration (e.g. resolution) will stay the same (https://github.com/w3c/mediacapture-screen-share/issues/308 might change this). Nice separation of concerns or foot-gun? YMMV. I'm no fan of events that require websites to decode their cause, because some inevitably get it wrong. > ... the screenshare session (and so the surface change) is owned by a single page, there should be no fuzzing. Agreed. Just unfortunate for the `configurationchange` event to have such different timing semantics per source category. > Updating the settings before the callback makes sense to me, ... Can you elaborate on why that makes sense to you? A singular upstream switch might cause a fan-out reaction of events on track clones potentially across multiple workers and main thread here. Seems simpler for websites to keep track of what's going on (no pun intended) if they're informed of the cause first. Doubly so if there are no events (no net configuration change). -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/15#issuecomment-2529663768 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 9 December 2024 22:24:04 UTC