[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Greg Simon]

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
another quirk.

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
> 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.
> >>
> >> I think the design guidelines introduced in the following Mozilla
> position
> >> paper are still valid. In this context, specifically:
> >>
> >> [[
> >>
> >> Device APIs should be asynchronous; in particular, user agents should
> not
> >> have to block on return values of Device API function calls, and Device
> APIs
> >> 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.
>  Instead,
> > 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
> known
> > 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
> orientation
> > before generating its content.  It would need to asynchronously query
> both
> > 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.
>
>
> Thanks,
> Andrei
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110617/19e1a6f7/attachment.html>