Limit when configurationchange fires to useful cases.

[jan-ivar]

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 #80 (comment):

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]

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]

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]

I'm satisfied by these answers. Thanks!