battery icon indicating copy to clipboard operation
battery copied to clipboard

Expose getBattery to ServiceWorker

Open stefhak opened this issue 9 years ago • 8 comments

Sorry to be late to the party, but experimenting a bit with this feature on Chrome and Firefox I conclude that it is not available to ServiceWorkers. I think it could be useful there (e.g. the SW script checking if resources on the server have been updated, and download only if there is plenty of battery or the charger is connected). Has this been discussed?

stefhak avatar May 19 '16 11:05 stefhak

Yes. It was identified as a good candidate for future work (think v2), see: https://www.w3.org/2009/dap/wiki/FutureWork

anssiko avatar May 19 '16 11:05 anssiko

Thanks @anssiko.

stefhak avatar May 19 '16 11:05 stefhak

However, the only change would be adding something like [Exposed=(Window, Worker)] , right? Feels like a small thing to add to v1 (and even if worker exposure is not part of v1 [Exposed=Window] should be added(?).

stefhak avatar May 19 '16 11:05 stefhak

The spec change is trivial, but the involved process is not.

The spec is now at PR. To add this new feature, we'd need to go back to WD, then CR and then again to PR and demonstrate interoperability i.e. wait for the existing implementations to update themselves and update the test suite as well.

anssiko avatar May 19 '16 11:05 anssiko

I understand (I was just trying to push a bit :-) perhaps I should push on implementers instead).

stefhak avatar May 19 '16 11:05 stefhak

I'll keep this issue open to collect feedback from implementers. If there's interest to expose this API to workers, I'll start work on v2.

One known issue in exposing to workers is of user consent. As of now, this API does not require user consent in any of the known implementations, but it could be that some future implementations might want to gate this behind a user prompt or some such. The getBattery() promise is there to provide an extension point for that.

anssiko avatar May 19 '16 11:05 anssiko

Sounds good!

As for user consent: the path we've lately taken for gUM is to use the Permission API. This could be an opportunity (the page could ask for persisted permission to use getBattery which should carry over to a worker of the same origin; the worker script could check if it has permission and skip calling getBattery if not).

stefhak avatar May 19 '16 12:05 stefhak

That's an interesting idea. Has that been field tested with any API? Related, for permission delegation to embedded web content (in an <iframe>), there's a rought idea: https://noncombatant.github.io/permission-delegation-api/

anssiko avatar May 19 '16 13:05 anssiko