[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
gregsimon at chromium.org
Fri Jun 17 10:42:35 PDT 2011
We ran into this problem on webOS with orientation where we did not want to
have the UI drawn "wrong" the first time and then (eventually) re-layed out
and painted at the correct device orientation. It looked VERY sloppy and
web-page-ish, not what we were trying to accomplish. Sure we could have
gamed the UA and transmitted the orientation at *just the right time* when
the app launched, but that would have been a nasty race condition and yet
For battery display we used the a proprietary XHR-type with subscription so
we could initialize the battery UI+level, and then get updates as the
proposed spec is shooting for.
On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu <andreip at google.com> wrote:
> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher <darin at chromium.org> wrote:
> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
> > <anssi.kostiainen at nokia.com> wrote:
> >> Hi,
> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> >> >
> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
> >> > <anssi.kostiainen at nokia.com> wrote:
> >> >
> >> > On 15.6.2011, at 21.29, ext Darin Fisher wrote:
> >> >
> >> > > There should probably be a way to poll the current state. Much as
> >> > > can poll the document.readyState and respond to progress events, it
> >> > > seem to make sense to have a way to poll the battery state as well
> >> > > 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
> >> > Let me know if you'd like me to dig into archives for some pointers on
> >> > design decision.
> >> >
> >> > I'd be curious to read them. Off-hand it seems like device
> >> > 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.
> >> I think the design guidelines introduced in the following Mozilla
> >> paper are still valid. In this context, specifically:
> >> [[
> >> Device APIs should be asynchronous; in particular, user agents should
> >> have to block on return values of Device API function calls, and Device
> >> should be driven by callbacks.
> >> http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous
> >> ]]
> > The proposal wasn't to make blocking APIs that query any devices.
> > you would be able to get synchronous access to the last known value for a
> > device property ("last known battery state", "last known device
> > orientation", etc.). In particular, you would get access to the last
> > value prior to your page being loaded.
> > Synchronous access to this value seems helpful for the reasons stated in
> > this thread. But, let me expand on that for a moment. Suppose an
> > application wanted to know both the battery state and the device
> > before generating its content. It would need to asynchronously query
> > states before proceeding. That seems quite awkward, especially when the
> > information could be provided synchronously.
> In the case of device orientation, having such a synchronous property
> would probably mean having the UA do a lot of wasted work, constantly
> exercising the underlying hardware just in case some Web app might
> need this information at start-up. However, I think it's reasonable to
> expect that Web apps using this API will be built in such a way that
> they will do work in response to orientation changes, so it's perhaps
> natural for them to treat the initial orientation the same way.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev