1314076 - Expose Battery API to WebExtensions

Status: REOPENED

(WebExtensions :: General, enhancement, P5)

Description

[Andrea Marchesini [:baku]]

This is a follow up of bug 1313580. Recently we removed Battery API from content.
Would be nice to have battery API exposed to WebExtensions.

Comment 1

[Kris Maglione [:kmag]]

I'd be in favor of this as long as we're committed to continue supporting the platform side of this. I really don't want to add support only to kill it if we decide it's not worth the maintenance burden.

Comment 2

[Andrea Marchesini [:baku]]

We use the battery check in platform to know when it's time to do some -potentially heavy- I/O on the profile directory.
QuotaManager uses the hal backend directly for this purpose, and definitely, we don't want to remove this feature.

Comment 3

[Kris Maglione [:kmag]]

Good to hear.

In that case, I think it's mostly just a question of how we want to expose it, and whether it should require special permissions to access.

Comment 4

[Caitlin Neiman [:caitmuenster]]

To be discussed at Nov. 15, 2016 web extensions triage meeting.

Comment 5

[Chris Peterson [:cpeterson]]

Andy, what new work is necessary to expose the Battery API to web extensions? The API is available today via navigator.getBattery().

Comment 6

[Kris Maglione [:kmag]]

Depending on whether we want this to be available to all extensions or to require a permission, we just need to either add a WebIDL attribute to check for extension principals, or expose it via the permission manager.

Comment 7

[Andrew Swan [:aswan]]

(In reply to Kris Maglione [:kmag] from comment #6)
> Depending on whether we want this to be available to all extensions or to
> require a permission, we just need to either add a WebIDL attribute to check
> for extension principals, or expose it via the permission manager.

Or create a bespoke principal check and invoke it with:
https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings#Func

Comment 8

[Andy McKay]

I was originally thinking that it would make sense to have a permission for this so that users could see that it was being requested, given that the original reason for removal for web sites was that it could be used for fingerprinting. Kris and others pointed out that once you've got an extension installed there are so many other ways to fingerprint a user. 

I'd support not bothering with a permission now would that be ok for you Chris?

Comment 9

[Chris Peterson [:cpeterson]]

(In reply to Andy McKay [:andym] from comment #8)
> I'd support not bothering with a permission now would that be ok for you
> Chris?

Sounds good to me. I don't think we should bother doing much extra work here. There are very few extensions or websites that use the Battery API today. While websites have used the battery information to fingerprint users, extensions have easier and more accurate ways to track users. I don't think exposing battery information to extensions without a new permission is worth the worrying about.

Comment 10

[u597032]

Battery API is no longer supported.

Comment 11

[Andrew Swan [:aswan]]

Can you please clarify comment 10?  If the comment is about the battery api no longer being available to web content, that's not really relevant here (and is explicitly discussed in previous comments).  If the comment is about removing platform support, can you please link to a specific bug that details that work?

In any case, we have an experimental webextension api here:
https://github.com/Happy-Ferret/ext-battery

Comment 12

[MarkBauer]

The Battery API is only no longer supported in the sense that it's not available to web content (see Bug 1313580 -- Part 3 of the patch set, in particular).

It's still available to Chrome privileged scopes.

Thanks for re-opening the issue, Andrew!

I'm really excited to work on this. Hoping to push v0.2 of ext-battery sometime later this week.
Not much in the way of code cleanup/refactoring (which, admittedly, it dearly needs) but at least I'll have all Events properly implemented and tested by then.

Comment 13

[Andrew Swan [:aswan]]

Mark, thanks for the work you've done so far on the experiment.  However, we can do some work to just expose the old DOM API to webextensions (or just to those that have a "battery" permission or something).  Are there other reasons I'm overlooking for creating an extension-specific API, or should we just follow that path?

Comment 14

[MarkBauer]

If you can do that safely without exposing too much of "navigator", sure.
I do think it would be better to establish an API that actually follows all the rules and standards of a Webextension API and can be documented along them.

Furthermore, it's worth pointing out that "battery.chargingTime" doesn't seem to return a valid result but either "Infinity" (when it's charging or not charging but also not fully charged) or "0" (when the battery is fully charged).

Comment 15

[Andrew Swan [:aswan]]

(In reply to MarkBauer from comment #14)
> If you can do that safely without exposing too much of "navigator", sure.

Yes, the obvious thing would be to just expose getBattery() to extensions.

> I do think it would be better to establish an API that actually follows all
> the rules and standards of a Webextension API and can be documented along
> them.

Not sure what you mean by this.  Do you mean something in the browser.* namespace instead of hanging off window.navigator?  We actually prefer DOM APIs to extension-specific APIs under browser when they exist...

> Furthermore, it's worth pointing out that "battery.chargingTime" doesn't
> seem to return a valid result but either "Infinity" (when it's charging or
> not charging but also not fully charged) or "0" (when the battery is fully
> charged).

That sounds worth filing a separate bug for.  I don't know much about the platform handling of this API but I'm sure its platform-dependent so including detailed information about your OS, hardware, etc. would be helpful.

Comment 16

[MarkBauer]

(In reply to Andrew Swan [:aswan] from comment #15)
> (In reply to MarkBauer from comment #14)
> > I do think it would be better to establish an API that actually follows all
> > the rules and standards of a Webextension API and can be documented along
> > them.
> 
> Not sure what you mean by this.  Do you mean something in the browser.*
> namespace instead of hanging off window.navigator?  We actually prefer DOM
> APIs to extension-specific APIs under browser when they exist...
> 

Among other things, yes.

Personally, as a developer who also dabbles in Webextensions, it feels more natural to me to establish an event listener
by calling "browser.battery.onLevelChanged.addListener(functionName)" than by setting it up as follows:

```
navigator.getBattery().then(function(battery) {
  battery.addEventListener('levelchange', functionName)
}
```

The latter not only requires new developers to write more code than should be necessary, it's also error prone because one might accidentally type 'levellchange' (or any other variation) and be non-the-wiser about failing/non-returning event listeners.

Furthermore, a new API could provide pre-formatted or otherwise sanitized results. So instead of "Infinity" we can already provide a more informative string.

Perhaps I'm slightly misguided on the issue, but IMHO it would be preferable to provide a higher level of
abstraction for content developers, rather than forcing them to sift through low level documentation or make mistakes that could be easily avoided through the use of said abstraction.

> > Furthermore, it's worth pointing out that "battery.chargingTime" doesn't
> > seem to return a valid result but either "Infinity" (when it's charging or
> > not charging but also not fully charged) or "0" (when the battery is fully
> > charged).
> 
> That sounds worth filing a separate bug for.  I don't know much about the
> platform handling of this API but I'm sure its platform-dependent so
> including detailed information about your OS, hardware, etc. would be
> helpful.

It's probably Windows specific, yes.
I intended looking into it yesterday afternoon but then got struck by personal issues.

Hopefully I'll be able to at least try it under Mac OS and GNU/Linux today, then debug a possible Windows solution over the weekend (fingers crossed).

Comment 17

[u597032]

I'm sorry. I think I misunderstood something.

Comment 18

[Alfonso Martinez]

Besides WebExtensions, this api would be useful also for Webapps.

As explained in https://bugzilla.mozilla.org/show_bug.cgi?id=1313580#c24 when a webapp is installed and used in a locked device which provides only this screen for the user (no other OS notifications or UI), it would be great to be able to check the battery status and give a warning when the battery is running low.

I understand that a "normal" webpage shouldn't have access to things like my battery status, but when I'm installing an app (webapp) I'm giving them more power and at least it should be able to prompt the user (after install) to grant access to the API.