WebKit implemented the battery API, though Safari didn't expose the API
to web content. Yesterday the WebKit team proposed removing the API, too:
https://bugs.webkit.org/show_bug.cgi?id=164213
https://lists.webkit.org/pipermail/webkit-dev/2016-October/028468.html
On 10/31/2016 1:24 AM, Chris Peterson wrote:
As proposed earlier on the dev-platform list [1], I made the Battery
Status API chrome-only in Firefox Nightly 52 (bug 1313580 [2]). The
battery code and tests remain, available to Gecko code and Firefox add-ons.
There should be little risk of web compat regressions. The battery API
was never implemented by IE, Edge, or Safari, so web content should
already be feature-detecting the API. Also, I know of no non-trivial
websites using the API for anything other than fingerprinting users in
the four years since Firefox introduced the API in 2012 (Firefox 10
[3]). Chrome added support in 2014.
We always have the option to make the API available to web content again
if a website or app demonstrates an interesting use case using Chrome's
battery API. However, I feel the supposed use cases for the battery API
would be better served by something like a lifecycle event API that
includes low battery/memory warnings. That would expose less identifying
information and allow the user and UA to customize the lifecycle settings.
[1]
https://groups.google.com/d/msg/mozilla.dev.platform/5U8NHoUY-1k/9ybyzQIYCAAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1313580
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=678694
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
