- From: Will Morgan via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Apr 2022 14:35:20 +0000
- To: public-device-apis-log@w3.org
Yep, happy to look over any feedback Mozilla submit on the proposal. [This is the only feedback I've seen so far](https://github.com/mozilla/standards-positions/issues/623#issuecomment-1090028687), from @annevk. > Have you done an evaluation of how native platforms approach this? That might also help with figuring out how to address the open design issues. Yes. On iOS and Android it's a synchronous call to the native API that sets brightness to a given value. > In general a request for this, similar to wake lock, seems okay. I'd be inclined to not give apps the result of such a request though and end users should always be able to override or automatically ignore such requests (ideally without the apps knowing). At a minimum the use case I've submitted requires to know whether it fulfilled or not, but not necessarily the reason why the request was denied. An analogous example of this is the [HTMLVideoElement.play() method throwing a deliberately vague `NotAllowedError`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/play#exceptions) to avoid fingerprinting the device if, for example, video autoplay is disabled due to low battery or user preference. -- GitHub Notification of comment by willmorgan Please view or discuss this issue at https://github.com/w3c/screen-wake-lock/issues/335#issuecomment-1105302817 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 April 2022 14:35:21 UTC