canx.cao@ I'm not sure it is a bug. It is not supported on Windows. GenericSensor API reports 'NotSupported' error correctly. I will change this bug to feature-request.

OK, thanks.
BTW, may I know if OrientationSensor will be implemented on Mac and Linux?

Mac - no plans at the moment.
Windows and Linux - we need to implement generic fusion algorithm that will provide data for Absolute and Relative orientation sensors.

juncai@ started a RELATIVE_ORIENTATION implementation for macOS based on its accelerometer: https://codereview.chromium.org/2929603003/

It would be nice to see this algorithm made generic (and support a fusion of multiple sensors if they are available).

reilly@ that is great!

canx.cao@ maybe you can follow https://codereview.chromium.org/2929603003/ and test when it lands. I think you will need HW with sudden motion sensor.

alexander.shalamov@, I found a note in https://support.apple.com/en-us/HT201666
Computers with Solid State Drives (SSD) or Flash Storage do not use SMS as the drives have no moving parts.

And I also chated with apple supporter, he told me that all the macbooks have gone to flash storage, so none of them would have it any longer.It would likly not be on any MacBook moad in at least the last 5 years.

We don't have any macbooks support the Sudden Motion Sensor.

reilly@ juncai@ Do we need to add fusion for RelativeOrientation on Windows? I think there was CL but it was abandoned.

The abandoned CL is:
https://chromium-review.googlesource.com/c/592108
The argument for this is that in the current device orientation event implementation on Windows, RelativeOrientation falls back on AbsoluteOrientation:
https://cs.chromium.org/chromium/src/device/sensors/data_fetcher_shared_memory_win.cc?l=231-261
So to match this, the RelativeOrientation is not implemented on Windows.

It's a very simple change to make this work. The question is whether it makes more sense for the API to encourage applications to implement their own fallback to the AbsoluteOrientationSensor or if this is something the platform should do for them.

What do the spec authors think?

Another thought I had looking at the spec is that it requires an extra permission token ("magnetometer") to request the AbsoluteOrientationSensor. Chrome is not currently distinguishing between these permissions but it does seem unexpected to silently upgrade a request to a sensor with more privilege.

Hi, reilly@, Juncai@ and Alexander@, WebVR/XR is now using RelativeOrientationSensor for MagicWindow feature which is blocked(#820308) on Windows by this issue, while works well on Android. As the RelativeOrientationSensor interface is shipping, would it be better to have implementation for all platforms.

Looking at the Windows API there doesn't appear to be a relative orientation sensor available on the platform. The right answer is either for the application to fall back to using an AbsoluteOrientationSensor or to fake it on this platform and return data from the absolute sensor ourselves.

Given the permissions issues associated with falling back to the absolute orientation sensor I think we should deploy our fusion relative orientation sensor on Windows. 

I'll start working on that soon.

juncai@ started a change to fix this issue (https://crrev.com/c/1053414/) but it highlighted a problem in that on Windows we cannot synchronously determine whether a sensor is supported by the platform. In  issue 224849  I fixed a simple case where this was possible but the general solution is to move all of our sensor fusion fallback logic into a single place that sits on top of all the platform-specific PlatformSensorProvider implementations and can asynchronously traverse the graph of possible fallbacks.