Add support for background blur and configuration change event

[youennf]

Related to #47.
Somehow related to #45 as well.

---

💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on May 19, 2022, 9:21 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.

🔗 Related URL

📡 HTTP Error 404: http://labs.w3.org/spec-generator/uploads/YpAWrK

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[alvestrand]

The most interesting part here is actually the "onconfigurationchange" event, because that applies to all configuration changes, not just this one.

When should it fire?

[youennf]

When should it fire?

The current wording gives some leeway, since this will be triggered by the UA or the OS.
I see a few possibilities:

1. Fire whenever capabilities change: the event should fire no matter what. For instance background blur can go from [true, false] to [true] when user decides to switch on background blur at the OS level. This might in turn change constraints or settings values.
2. Fire whenever capabilities, constraints or settings change, outside of changes triggered by applyConstraints. This has a broader scope.

I would be tempted to go with option 1 for now since it fits the usecase.
I used onconfigurationchange and not oncapabilitieschange to cover the fact that settings/constraints might change in addition to capabilities.

Also, onconfigurationchange could provide the list of changed properties if this can prove useful.

[youennf]

I would be tempted to go with option 1 for now since it fits the usecase.

Actually no, in the case of OS allowing to change the value but still allowing the web app to override the value, the UA might either ignore OS (would be bad) or would only change the settings, not the capabilities.
So, the best choice is probably to fire whenever capabilities, constraints or settings change outside of changes triggered by applyConstraints.

[eehakkin]

For the background blur support, we have been working on an explainer as suggested by the WG staff dontcallmedom (after agreeing with the WG chairs I presume). Would it be OK for you to continue discussion on the background blur through that explainer process?

[youennf]

Discussed with @jan-ivar, we should add the possibility to fuzz time the event firing to prevent document correlation

[youennf]

@eehakkin, we will be discussing bb blur and https://github.com/riju/backgroundBlur/blob/main/explainer.md at next WebRTC interim. I'll be writing some slides. Can we sync before the meeting, say next Monday maybe?

[youennf]

This was discussed at last WebRTC interim and reached rough consensus at that time.
We start with a boolean constraint but should investigate double constraints.