Add device motion enable switch to about:flags in Chrome for Android.

Add device motion enable switch to about:flags in Chrome for Android.

BUG=135804
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=211516

[Peter Beverloo, 2013-06-20 15:56:25]

This sounds like an excellent feature to be part of the existing "Enable
experimental WebKit features" group.  What do you think?

[timvolodine, 2013-06-20 16:05:06]

On 2013/06/20 15:56:25, Peter Beverloo wrote:
> This sounds like an excellent feature to be part of the existing "Enable
> experimental WebKit features" group.  What do you think?

Sounds good, but we probably want a more granular switching. The device motion
switch is currently only defined for Android, while the
experimental-webkit-features is defined for all OS types.

[Peter Beverloo, 2013-06-20 16:14:49]

On 2013/06/20 16:05:06, timvolodine wrote:
> Sounds good, but we probably want a more granular switching. The device motion
> switch is currently only defined for Android, while the
> experimental-webkit-features is defined for all OS types.

Without a backend implementation we can be sure that non-Android platforms can
*never* supply Device Motion data.

Per the specification, we should be firing exactly one devicemotion event with
all properties set to NULL.  This will tell the developer that support is not
available.  I suppose this behavior has not been implemented yet?

When we run-time enable Device Motion, it is true that the DeviceMotionEvent
will be web exposed.  That may possibly break feature detection for certain
websites.

If we can easily add the one-shot NULL event, which we'll need to support in
either case (for Android devices without the proper sensors as well), I have a
slight preference for including this feature behind the experimental WebKit
features-flag.

[timvolodine, 2013-06-21 15:33:24]

On 2013/06/20 16:14:49, Peter Beverloo wrote:
> On 2013/06/20 16:05:06, timvolodine wrote:
> > Sounds good, but we probably want a more granular switching. The device
motion
> > switch is currently only defined for Android, while the
> > experimental-webkit-features is defined for all OS types.
> 
> Without a backend implementation we can be sure that non-Android platforms can
> *never* supply Device Motion data.
> 
> Per the specification, we should be firing exactly one devicemotion event with
> all properties set to NULL.  This will tell the developer that support is not
> available.  I suppose this behavior has not been implemented yet?
> 
> When we run-time enable Device Motion, it is true that the DeviceMotionEvent
> will be web exposed.  That may possibly break feature detection for certain
> websites.
> 
> If we can easily add the one-shot NULL event, which we'll need to support in
> either case (for Android devices without the proper sensors as well), I have a
> slight preference for including this feature behind the experimental WebKit
> features-flag.

There is support for firing NULL for the Android platform. In principle we could
provide empty fetchers for the other platforms, however I don't see a clear
benefit of doing this at this point.
Also the http://www.html5rocks.com/en/tutorials/device/orientation/#toc-dm1
seems to suggest testing the availability of device motion using:
if (window.DeviceMotionEvent) { ... }

It is my understanding that firing NULL values is meant in case we cannot
provide device motion on a particular machine simply because there are no
appropriate sensors for it. In addition to that firing NULL seems to break
device motion website such as html5rocks.com because it tries to use the values
for computation. So in this case it seems better to just disable device motion
altogether for platforms other than Android, and add more platforms as the
respective fetchers get implemented.

[timvolodine, 2013-06-27 22:50:45]

Jochen, can we have an lgtm for this?

[jochen (gone - plz use gerrit), 2013-06-28 08:53:06]

I was hoping Peter would comment first.

Anyway, the switch is defined for all platforms (and you've put it outside of
#if defined(OS_ANDROID), so I tend to agree with Peter

[timvolodine, 2013-06-28 21:49:36]

On 2013/06/28 08:53:06, jochen wrote:
> I was hoping Peter would comment first.
> 
> Anyway, the switch is defined for all platforms (and you've put it outside of
> #if defined(OS_ANDROID), so I tend to agree with Peter

ok, I'll consult with Peter about this.

In particular it is not clear from the spec if the NULL event should be fired
once or multiple times (in the case there are no sensors available). Maybe I am
mistaken here but it was my understanding it should be fired multiple times as
normal events would but with all values set to null..
Also if this feature goes behind the experimental WebKit features what will
happen to the existing enable-device-motion flag? i.e. do we need to support
both flags or just put device motion behind the experimental-webkit flag?

[jochen (gone - plz use gerrit), 2013-07-01 09:14:23]

On 2013/06/28 21:49:36, timvolodine wrote:
> On 2013/06/28 08:53:06, jochen wrote:
> > I was hoping Peter would comment first.
> > 
> > Anyway, the switch is defined for all platforms (and you've put it outside
of
> > #if defined(OS_ANDROID), so I tend to agree with Peter
> 
> ok, I'll consult with Peter about this.
> 
> In particular it is not clear from the spec if the NULL event should be fired
> once or multiple times (in the case there are no sensors available). Maybe I
am
> mistaken here but it was my understanding it should be fired multiple times as
> normal events would but with all values set to null..
> Also if this feature goes behind the experimental WebKit features what will
> happen to the existing enable-device-motion flag? i.e. do we need to support
> both flags or just put device motion behind the experimental-webkit flag?

I started a thread on blink-dev about this. Feel free to chime in.

[jochen (gone - plz use gerrit), 2013-07-01 18:00:59]

ok, based on the blink-dev thread this lgtm

[Peter Beverloo, 2013-07-12 18:28:52]

Much belated lgtm.  Apologies for that!

[cpu_(ooo_6.6-7.5), 2013-07-12 19:56:49]

grd changes should be TBR

[commit-bot: I haz the power, 2013-07-12 19:58:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/timvolodine@chromium.org/17370006/14001

[commit-bot: I haz the power, 2013-07-13 03:03:37]

Change committed as 211516