[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

Darin Fisher darin at chromium.org
Thu Jun 16 09:02:29 PDT 2011


On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen <
anssi.kostiainen at nokia.com> wrote:

> 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.
>
>
I'd be curious to read them.  Off-hand it seems like device orientation
suffers from the same problem.  You wouldn't want the application to do too
much work that would be discarded once it finds out that the orientation is
X instead of Y.

It seems like this is information that we have available immediately, and it
is a bit unfortunate that page authors need to delay initialization until
they receive the initial orientation or battery status event.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110616/ff1a3eac/attachment.html>


More information about the webkit-dev mailing list