WebKit position on Wake Lock API
Hello WebKit Dev, Following Maciej's invitation to send requests for positions on API proposals to this very mailing list, I would like to gauge WebKit's position on the Wake Lock API: https://bugs.webkit.org/show_bug.cgi?id=205104. Nota bene, this is an API that is potentially useful for a "document web" even, not just an "application web". Thanks, Tom
Is there a Blink Intent thread currently running on this or about to start? And do you happen to know if there is a Mozilla standards-positions issue on this? (We like to take into consideration whet the other browser engines are thinking.)
On Dec 10, 2019, at 11:46 PM, Thomas Steiner <tomac@google.com> wrote:
Hello WebKit Dev,
Following Maciej's invitation to send requests for positions on API proposals to this very mailing list, I would like to gauge WebKit's position on the Wake Lock API: https://bugs.webkit.org/show_bug.cgi?id=205104 <https://bugs.webkit.org/show_bug.cgi?id=205104>. Nota bene, this is an API that is potentially useful for a "document web" even, not just an "application web".
Thanks, Tom
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Wed, Dec 11, 2019 at 11:42 AM Maciej Stachowiak <mjs@apple.com> wrote:
Is there a Blink Intent thread currently running on this or about to start? And do you happen to know if there is a Mozilla standards-positions issue on this? (We like to take into consideration whet the other browser engines are thinking.)
https://github.com/mozilla/standards-positions/issues/210 is Mozilla's standards position issue.
On Dec 10, 2019, at 11:46 PM, Thomas Steiner <tomac@google.com> wrote:
Hello WebKit Dev,
Following Maciej's invitation to send requests for positions on API proposals to this very mailing list, I would like to gauge WebKit's position on the Wake Lock API: https://bugs.webkit.org/show_bug.cgi?id=205104. Nota bene, this is an API that is potentially useful for a "document web" even, not just an "application web".
Thanks, Tom
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
The Intent to Experiment thread is here: https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/nrDKOvVl_I4... On Wed 11. Dec 2019 at 22:08 Ryosuke Niwa <rniwa@webkit.org> wrote:
On Wed, Dec 11, 2019 at 11:42 AM Maciej Stachowiak <mjs@apple.com> wrote:
Is there a Blink Intent thread currently running on this or about to start? And do you happen to know if there is a Mozilla standards-positions issue on this? (We like to take into consideration whet the other browser engines are thinking.)
https://github.com/mozilla/standards-positions/issues/210 is Mozilla's standards position issue.
On Dec 10, 2019, at 11:46 PM, Thomas Steiner <tomac@google.com> wrote:
Hello WebKit Dev,
Following Maciej's invitation to send requests for positions on API proposals to this very mailing list, I would like to gauge WebKit's position on the Wake Lock API: https://bugs.webkit.org/show_bug.cgi?id=205104. Nota bene, this is an API that is potentially useful for a "document web" even, not just an "application web".
Thanks, Tom
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
--
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.23 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. hTtPs://xKcd.cOm/1181/ -----END PGP SIGNATURE-----
We'll be discussing this internally at Apple but since we're heading into the holiday shutdown, we probably won't be able to get back to you until sometime next month. - R. Niwa On Wed, Dec 11, 2019 at 1:19 PM Thomas Steiner <tomac@google.com> wrote:
The Intent to Experiment thread is here:
https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/nrDKOvVl_I4...
On Wed 11. Dec 2019 at 22:08 Ryosuke Niwa <rniwa@webkit.org> wrote:
On Wed, Dec 11, 2019 at 11:42 AM Maciej Stachowiak <mjs@apple.com> wrote:
Is there a Blink Intent thread currently running on this or about to start? And do you happen to know if there is a Mozilla standards-positions issue on this? (We like to take into consideration whet the other browser engines are thinking.)
https://github.com/mozilla/standards-positions/issues/210 is Mozilla's standards position issue.
On Dec 10, 2019, at 11:46 PM, Thomas Steiner <tomac@google.com> wrote:
Hello WebKit Dev,
Following Maciej's invitation to send requests for positions on API proposals to this very mailing list, I would like to gauge WebKit's position on the Wake Lock API: https://bugs.webkit.org/show_bug.cgi?id=205104. Nota bene, this is an API that is potentially useful for a "document web" even, not just an "application web".
Thanks, Tom
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
--
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac)
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.23 (GNU/Linux)
iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. hTtPs://xKcd.cOm/1181/ -----END PGP SIGNATURE-----
Recipe sites have started to use this: https://twitter.com/ChromiumDev/status/1215343114166185985.
On Sat 21. Dec 2019 at 02:18 Ryosuke Niwa <rniwa@webkit.org> wrote:
We'll be discussing this internally at Apple but since we're heading into the holiday shutdown, we probably won't be able to get back to you until sometime next month.
Hello Ryosuke, Have you or someone else from the team had a chance to look at this? Please note that we’re currently exclusively look for the “screen” wake lock case, not the “system” case. Thanks for a short update in advance. Cheers, Tom -- Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.23 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. hTtPs://xKcd.cOm/1181/ -----END PGP SIGNATURE-----
On Tue, Feb 18, 2020 at 5:23 AM Thomas Steiner <tomac@google.com> wrote:
On Sat 21. Dec 2019 at 02:18 Ryosuke Niwa <rniwa@webkit.org> wrote:
We'll be discussing this internally at Apple but since we're heading into the holiday shutdown, we probably won't be able to get back to you until sometime next month.
Hello Ryosuke,
Have you or someone else from the team had a chance to look at this? Please note that we’re currently exclusively look for the “screen” wake lock case, not the “system” case.
I'm still soliciting a feedback. For now, I can say we're very much concerned about any impact on battery life since that's no.1 thing our users care about. Since even a few percentage point of battery life regression would be a major concern, there *needs to be extraordinarily good reasons* to add this API; I just don't think any of the use cases listed in https://w3c.github.io/wake-lock/#introduction are compelling enough to meet such a standard. - R. Niwa
Hi Ryosuke, all, I'm still soliciting a feedback.
Thanks! For now, I can say we're very much concerned about any impact on battery
life since that's no.1 thing our users care about. Since even a few percentage point of battery life regression would be a major concern, there *needs to be extraordinarily good reasons* to add this API;
As pointed out earlier, there is a workaround of playing an invisible video to keep the screen awake, and people are (ab)using it: https://github.com/mozilla/standards-positions/issues/210#issuecomment-57620... . This proposed API could be a proper way of having this feature, allowing user agents to display appropriate indications (see https://blog.tomayac.com/2018/12/18/experimenting-with-the-wake-lock-api/#cl... for my ideas). Since the screen is visibly on, the impact on battery life is very tangible; since there's no hidden background activity or anything that an app couldn't do anyways. Actually, iOS has started to show (add to home screen) Web.app activity in the Battery stats, so users can even trace battery consumption back to web apps.
I just don't think any of the use cases listed in https://w3c.github.io/wake-lock/#introduction are compelling enough to meet such a standard.
Looking at the _screen_ wake lock use cases: * Use turn-by-turn navigation while walking and driving and not interacting with the phone. Apple/Google Maps do that and need that on native. Both web apps could use this as well (Apple Maps is available on the web https://goo.gle/apple-hq-on-apple-maps, navigation isn't, but here's a navigation link for Google Maps: https://goo.gle/old-apple-to-apple-park-google-maps <https://www.google.com/maps/dir/1+Infinite+Loop,+Cupertino,+CA,+USA/Apple+Park,+One+Apple+Park+Way,+Cupertino,+CA+95014,+United+States/@37.3339405,-122.0296041,15z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x808fb5b7176a341d:0x4ae040c5bfc59fcd!2m2!1d-122.0301837!2d37.3318115!1m5!1m1!1s0x808fb596e9e188fd:0x3b0d8391510688f0!2m2!1d-122.0090499!2d37.334801!3e2> ). * Allow an external device to read a boarding card with a barcode on a phone. Starbucks have publicly requested this feature (combined with the capability to boost the screen brightness to the maximum brightness: https://github.com/w3c/wake-lock/issues/129#issuecomment-439713499). Their PWA is used by many of their customers. * Showing a presentation where each slide is shown for a prolonged period. Google Slides has this challenge. I'm biased, but all of those sound compelling to me. Cheers, Tom
participants (3)
-
Maciej Stachowiak
-
Ryosuke Niwa
-
Thomas Steiner