search

w3c / mediacapture-extensions

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

Add support for background blur and configuration change event #61

Closed youennf closed 2 years ago

youennf commented 2 years ago

Related to https://github.com/w3c/mediacapture-extensions/issues/47. Somehow related to https://github.com/w3c/mediacapture-extensions/issues/45 as well.

:boom: Error: 500 Internal Server Error :boom:

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: :rotating_light: [Spec Generator](https://www.w3.org/2015/labs/) - Spec Generator is the web service used to build specs that rely on ReSpec. :link: [Related URL](https://labs.w3.org/spec-generator/?type=respec&url=https%3A%2F%2Fraw.githubusercontent.com%2Fw3c%2Fmediacapture-extensions%2F983c54007c5a4aea293195df903994984b0c579a%2Findex.html%3FisPreview%3Dtrue) ``` 📡 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](https://github.com/tobie/pr-preview/issues/new?title=Error%20not%20surfaced%20properly&body=See%20w3c/mediacapture-extensions%2361.)._
alvestrand commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

youennf commented 2 years ago

@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 commented 2 years ago

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.