W3C home > Mailing lists > Public > public-device-apis-log@w3.org > November 2018

Re: [wake-lock] Need maximum screen brightness mode

From: Henrik Joreteg via GitHub <sysbot+gh@w3.org>
Date: Sun, 18 Nov 2018 18:16:57 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-439713499-1542565016-sysbot+gh@w3.org>
Hey folks! 👋  I'm the dev who first built that barcode screen on the Starbucks PWA.

I just have a couple of points of feedback. In my opinion, this is all in the interest of better supporting an entire class of applications that involve scanning a phone screen with a barcode reader. Insufficient contrast sometimes makes this harder, which is incredibly annoying. In the case of starbucks, if the PWA screen scan fails, then having to switch to the native app, or otherwise problem solve with the barista is incredibly frustrating. It transforms the experience from: "wow this is cool, look what a tech-savvy coffee-drinker I am" into "Crap, this is embarrassing, this app sucks, etc."

The main thing I originally asked for when we brought this up to Dion and others at Google a couple of years ago now was specifically:

1. A permission-gated way to temporarily ask for screen brightness to go to 100%
2. A way to ask the phone  to stay awake so you don't pull it up while waiting in queue at starbucks, then find yourself trying to tap the screen to keep it awake while you're waiting for the person in front of you to order their orange mocha frappuccino with extra whip and sprinkles :)

I would imagine an API for this being something along the lines of:

```js
window.requestWakeLock({fullScreenBrightness: true, timeout: 60000})
  .then(() => {
    // lock succeeded!
  })
  .catch(() => {
    // failed or rejected
  })
```

I really don't think there's a great usecase for reading screen brightness, or setting a specific brightness. It cause fingerprinting issues and frankly, feels like an OS-level concern that the user should get to decide. Again, this is all about enabling reliable scanning of phone screens.

The reason I suggested passing `fullScreenBrightness` as an option to a primary API of `requestWakeLock` instead of doing something like `requestFullScreenBrightness` is because I could see games and such wanting to prevent screens from falling asleep even if the user isn't tapping on the screen. Sometimes there are long in-game videos or animations where avoiding the screen going to sleep would be nice. So doing a wake-lock without adjusting screen brightness seems like a valid use case.

And, I think any time you want to enable screen scanning (barcodes, etc), it makes sense to keep the screen alive as often there's waiting involved, and having the screen go to sleep while actively trying to scan a phone is super annoying.

Anyway, that's just my two cents. I would love to see something along these lines land in browsers. Seems like something that would improve UX on the web for a large number of use cases.

-- 
GitHub Notification of comment by HenrikJoreteg
Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/129#issuecomment-439713499 using your GitHub account
Received on Sunday, 18 November 2018 18:16:58 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 18 November 2018 18:16:59 UTC