[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Anssi Kostiainen]

Hi,

On 15.6.2011, at 20.25, ext Greg Simon wrote:

> From what I can tell the spec offers no way for the web application to initialize any algorithm based on the battery/power state because there is no guarantee of "minimum time" when a new document is created and the first battery event arrives. Ideally there would be a way to "kick" the UA into sending the battery event on demand. 

To keep the "minimum time" as small as possible, the first BatteryStatusEvent should be fed into an appropriate task queue upon event listener registration. An excerpt from the spec:

[[

When an event listener is registered with the event type batterystatus, then the User Agent must retrieve the relevant information and dispatch a BatteryStatusEvent event asynchronously as defined in [DOM-LEVEL-3-EVENTS].       

]]

The relevant section in the D3E spec would be:

  http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#sync-async

> Otherwise the web application starts at full-throttle (burning battery) on a device with 10% battery left until it *drains* enough to get a batteryEvent.

I agree we'll need to handle that case, and that's why the above-mentioned requirement is in the spec.

On 15.6.2011, at 21.29, ext Darin Fisher wrote:

> There should probably be a way to poll the current state.  Much as you can poll the document.readyState and respond to progress events, it would seem to make sense to have a way to poll the battery state as well as respond to battery state change events.

The current design is quite similar to that of the Device Orientation Event. We discussed the polling option but settled on the current design. Let me know if you'd like me to dig into archives for some pointers on that design decision.

-Anssi