search

w3c / mediacapture-extensions

Extensions to Media Capture and Streams by the WebRTC Working Group
https://w3c.github.io/mediacapture-extensions/
Other
19 stars 15 forks source link

Limit when configurationchange fires to useful cases. #87

Closed jan-ivar closed 1 year ago

jan-ivar commented 1 year ago

The spec currently says: "When the User Agent detects a change of configuration in a track's underlying source, the User Agent MUST run the following steps: ... 3. If track's capabilities, constraints and settings are matching source configuration, abort these steps. "

...which supports this conversation https://github.com/w3c/mediacapture-extensions/pull/80#issuecomment-1440137816:

It would be odd if the name was oncapabilityandorsettingchange or if the name was onsettingchange and the event were triggered when only the capability changed without a setting change.

Why should an event fire if a capability changed without affecting the setting?

I suppose if blur becomes available in the OS then this is useful information. Thanks for explaining!

So it seems useful to fire the event when a new capability becomes available to the app.

But if a capability that the app is not using is removed, then there seems to be no reason to fire an event. It may also be hard for a user agent to keep track of capabilities that aren't in use.

I think we should be more specific about when the event fires and not fire when an unused capability disappears. This ensures every functionality added has a use case.

eladalon1983 commented 1 year ago

But if a capability that the app is not using is removed, then there seems to be no reason to fire an event.

What if the app is exposing user-facing controls to manipulate the setting? It might wish to remove, grey out, or otherwise disable that user-facing control.

youennf commented 1 year ago

I am also not sure what means an unused capability. One potential implementation is to generate the dictionaries, compare them and decide whether to fire an event if they are the same. This seems simple enough and more interoperable than trying to either have precise rules to when fire the event or let this to UAs.

jan-ivar commented 1 year ago

I'm satisfied by these answers. Thanks!