Intent to Change: devicemotion's rotationRate

[jun...@chromium.org]

Spec:

https://w3c.github.io/deviceorientation/spec-source-orientation.html#devicemotion

Related chromium issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=541607

Summary:

The spec says the devicemotion's rotationRate "must be expressed in degrees per second (deg/s)". I did some testing on Chrome on Android, Firefox browser on Android, and Safari browser on iPhone, Firefox browser and Safari browser use degrees, but Chrome uses radians which is different from the spec. So we would like to change this to be the same as the spec.

[Chris Harrelson]

Hi,

Is there a use counter for this feature, to estimate compatibility risk?

Chris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8a746dc3-024b-4bd2-ade4-343352f17c67%40chromium.org.

[Rick Byers]

I don't see a UseCounter, but the DeviceMotion UseCounter is at around 0.1% so that's an upper bound.  I did a quick http archive search and found about 1000 pages (0.2% of top 500k sites), and looking at a random sample of a few of them the usage all seemed to be some generic ad network code for posting device motion data down into ad frames (though the specific ads I received weren't actually using it as far as I could see from a quick code search).

Given that Firefox and Safari agree, that the severity of breakage is likely low, and that the upper bound on pages impacted and usage impacted is both only moderate (with good reason to believe the actual impact is mucher lower - anecdotally most users of deviceMotion likely don't care about the rotationRate) I think the compat risk here is quite low.  Applying our "is this something we'd need to update MDN docs for" smoke test, I'd personally be comfortable calling this a bug fix, not an API change that requires an intent.  But (like all bug fixes) if we get reports of breakage in the wild, we should re-evaluate (including erring on the side of reverting in order to give time for a proper compat analysis).

Chris, WDYT?  Tim, as the DeviceMotion expert what's your judgement here?

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_EDx8LzNY3fpF13B-gDdOVzUj4%3D2yeGk2-ayq_54d8KQ%40mail.gmail.com.

[Chris Harrelson]

On Thu, Aug 24, 2017 at 8:17 AM, Rick Byers <rby...@chromium.org> wrote:

I don't see a UseCounter, but the DeviceMotion UseCounter is at around 0.1% so that's an upper bound.  I did a quick http archive search and found about 1000 pages (0.2% of top 500k sites), and looking at a random sample of a few of them the usage all seemed to be some generic ad network code for posting device motion data down into ad frames (though the specific ads I received weren't actually using it as far as I could see from a quick code search).

Given that Firefox and Safari agree, that the severity of breakage is likely low, and that the upper bound on pages impacted and usage impacted is both only moderate (with good reason to believe the actual impact is mucher lower - anecdotally most users of deviceMotion likely don't care about the rotationRate) I think the compat risk here is quite low.  Applying our "is this something we'd need to update MDN docs for" smoke test, I'd personally be comfortable calling this a bug fix, not an API change that requires an intent.  But (like all bug fixes) if we get reports of breakage in the wild, we should re-evaluate (including erring on the side of reverting in order to give time for a proper compat analysis).

Chris, WDYT?

I agree. Thanks for looking.

 

  Tim, as the DeviceMotion expert what's your judgement here?

Rick

On Thu, Aug 24, 2017 at 12:42 AM, Chris Harrelson <chri...@chromium.org> wrote:

Hi,

Is there a use counter for this feature, to estimate compatibility risk?

Chris

On Wed, Aug 23, 2017 at 11:58 AM, <jun...@chromium.org> wrote:

Spec:

https://w3c.github.io/deviceorientation/spec-source-orientation.html#devicemotion

Related chromium issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=541607

Summary:

The spec says the devicemotion's rotationRate "must be expressed in degrees per second (deg/s)". I did some testing on Chrome on Android, Firefox browser on Android, and Safari browser on iPhone, Firefox browser and Safari browser use degrees, but Chrome uses radians which is different from the spec. So we would like to change this to be the same as the spec.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8a746dc3-024b-4bd2-ade4-343352f17c67%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_EDx8LzNY3fpF13B-gDdOVzUj4%3D2yeGk2-ayq_54d8KQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_HFmpNOToPVMrYTDx6hthkdMLh6sQGuU_ytrEAjFQiaw%40mail.gmail.com.

[Rick Byers]

Thanks.  juncai@ if nobody objects on this thread in the next day or so I suggest you just proceed with this as a bug fix (but please the thread if you get reports of regressions after it lands).

[jun...@chromium.org]

On Thursday, August 24, 2017 at 9:41:52 AM UTC-7, Rick Byers wrote:

Thanks.  juncai@ if nobody objects on this thread in the next day or so I suggest you just proceed with this as a bug fix (but please the thread if you get reports of regressions after it lands).

Sure. Thanks Rick!

[Tim Volodine]

+1 for doing this as a bug fix, thanks for noticing this! IMHO we should stick to the spec, for compatibility reasons especially if other browsers implement it as deg/s.

[Reilly Grant]

For reference, this change will be shipping in Chrome 66.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8a746dc3-024b-4bd2-ade4-343352f17c67%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_EDx8LzNY3fpF13B-gDdOVzUj4%3D2yeGk2-ayq_54d8KQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dustin Kerstein]

One quick consideration -  I believe this change will break all existing Polyfilled WebVR sites whether they directly use the Polyfill or use something like A-Frame which has the Polyfill integrated. I know this represents a very tiny percentage compared to the rest of the web, but most people who are using these WebVR experiences don't likely have devices that fully support WebVR, so they rely on the Polyfill. And unless these developers are notified and take action before v66 goes stable, their sites are going to break. Is there anything that can be done to alleviate the disruption this could cause?

Thanks,

Dustin

[PhistucK]

Can you share the history of why radians were selected in the first place and when or why this got diverged?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[PhistucK]

Those polyfills had to accommodate both of the units (radians and degrees) anyway (if A-Frame is involved, I am pretty sure it works using Firefox too), so the only question is how they determined that radians should be used - user agent sniffing (in 2016/2017/2018?)? :S

Did you actually see an issue or is this just a speculation at this point?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87e96fa4-8706-484f-8ca4-502c13252bac%40chromium.org.

[jsan...@google.com]

That's correct, some UA parsing unfortunately to determine if the `rotationRate` is in degrees or radians[0]. Just sending out a patch now that parses for Chrome m66 and uses the degrees logic[1]. Unfortunately there's not a better way as far as we can tell outside of UA parsing. :[

 

Did you actually see an issue or is this just a speculation at this point?

If the WebVRPolyfill[2] doesn't anticipate the correct units, the rotation is wildly out of control and unusable. We'll be reaching out to developers that use the polyfill, encouraging to update with the fix[1] to prevent breakage once m66 hits stable. Hope this background info helps!

[0] https://github.com/immersive-web/cardboard-vr-display/blob/ed963c76e98de62dde37e8457a5389f2dec23965/src/sensor-fusion/fusion-pose-sensor.js#L156-L160

[1] https://github.com/immersive-web/cardboard-vr-display/pull/19

[2] https://github.com/immersive-web/webvr-polyfill

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87e96fa4-8706-484f-8ca4-502c13252bac%40chromium.org.

[jun...@chromium.org]

I noticed this when I was doing some refactoring work for the DeviceMotion/DeviceOrientation APIs. I am not familiar with the history of this.

[Dustin Kerstein]

Ok. Do we feel this is a necessary change at this point? While this can be worked around with an update to the Polyfill, all existing sites that use an older version of the Polyfill (including A-Frame) are going to be permanently broken by this change until developers notice / update their code. It just seems like it could be bad for the overall health / adoption of WebVR.

-Dustin

On Thursday, March 8, 2018 at 11:20:46 AM UTC-8, jun...@chromium.org wrote:

I noticed this when I was doing some refactoring work for the DeviceMotion/DeviceOrientation APIs. I am not familiar with the history of this.

On Saturday, March 3, 2018 at 2:40:15 AM UTC-8, PhistucK wrote:

Can you share the history of why radians were selected in the first place and when or why this got diverged?

☆PhistucK

On Wed, Aug 23, 2017 at 8:58 PM, <jun...@chromium.org> wrote:

Spec:

https://w3c.github.io/deviceorientation/spec-source-orientation.html#devicemotion

Related chromium issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=541607

Summary:

The spec says the devicemotion's rotationRate "must be expressed in degrees per second (deg/s)". I did some testing on Chrome on Android, Firefox browser on Android, and Safari browser on iPhone, Firefox browser and Safari browser use degrees, but Chrome uses radians which is different from the spec. So we would like to change this to be the same as the spec.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

Getting into interoperability is a necessary change. Otherwise, user-agent-sniffing third-party code would perpetuate the lack of interoperability, making new implementations encounter this quirk (hopefully not as a critical production bug). This is not a good state.

Whether the Chrome version is better (or interoperable with more code) than the standard version or not is another matter, though.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a40fa1a-ee5a-4574-af9d-2f3e2aafe10b%40chromium.org.

[jun...@chromium.org]

We still feel this is a necessary change. In the short term, it may cause some sites to have to update their code, but in the long term, by following the spec that other browsers already did, it will make all browsers behave the same for this DeviceMotion/DeviceOrientation APIs.

[Angelo Scandaliato]

It has been suggested to use agent sniffing to determine the measurement units. However using agent sniffing is not a great solution due to its own discrepancies.

Another suggestion could be to add an additional attribute that states the measurement units. I feel this could be the safest solution.

[PhistucK]

Where was user agent sniffing suggested? It is a very bad practice, I do not think you will find such suggestions here...

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/459e7b39-8631-4e53-8ba7-fb20db622f71%40chromium.org.

[Angelo Scandaliato]

Using the user agent was not suggested per say, however as of now it was the only mentioned solution to determine the units between chrome versions.

>  That's correct, some UA parsing unfortunately to determine if the `rotationRate` is in degrees or radians[0]. Just sending out a patch now that parses for Chrome m66 and uses the degrees logic[1]. Unfortunately there's not a better way as far as we can tell outside of UA parsing.

My concern is that a website has to take into account what browser and browser version is being used to determine the correct units. 

How do you propose websites handle unit discrepancies across chrome versions?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/459e7b39-8631-4e53-8ba7-fb20db622f71%40chromium.org.

[Rick Byers]

As much as I hate UA sniffs, using them as a version-bound blacklist to work around bugs is, IMHO, the main compelling use case. There are lots of times you need to work around a browser bug, and in general there's really no better option than a precise UA check for KNOWN broken browsers. As long as the condition says "if Chrome less than version 57" (or whatever), there is very little downside IMHO.  Eventually all chromes in the wild will be newer than 57 and the code becomes a no-op.

The problem with UA sniffing is really when you make assumptions about browsers you haven't tested.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/78b92237-f475-4b28-9993-74be467b6d4b%40chromium.org.

[jsan...@google.com]

As an FYI, the WebVR Polyfill was cut with a new release that handles the unit change to degrees in Chrome m66. As Chrome m65 is broken due to a separate issue, it's a good excuse to upgrade the version of the polyfill and get these unit changes for free. A pull request has already been set out to A-Frame to update their version of the polyfill.