Aframe: Sensor access disabled by default in Safari from iOS 12.2+

Created on 29 Jan 2019  Â·  28Comments  Â·  Source: aframevr/aframe

AFrame VR will no longer work on iOS according to the release of iOS 12.2b without changing the default Safari settings on devices:

https://github.com/w3c/deviceorientation/issues/57#issuecomment-458464696

Both deviceorientation and devicemotion sensors will be disabled by default in Safari from iOS 12.2+. Users will need to enable Settings > Safari > Motion and Orientation access to continue to use AFrame.

AFrame relies on polyfilling WebVR from these sensors on iOS via its dependency on webvr-polyfill (which in turn relies on cardboard-vr-display).

Blog post discussing change @ https://medium.com/@firt/pwas-on-ios-12-2-beta-the-good-the-bad-and-the-not-sure-yet-if-good-a37b6fa6afbf

Is there any plan to work around this change in AFrame?

mobile

Most helpful comment

iOS 13 is out and A frame isn’t requesting devicemotion API access on 0.9.2

All 28 comments

Those are bad news. Without access to sensors not sure if there’s anything we can do.

Looks like Generic Sensors is also not supported either. To be fair, deviceorientation and devicemotion are terribly abused APIs, but not sure of a work around currently for iOS.

There is a W3C thread on this here (specifically about adding a permission pop up) be sure to comment how important it is that this gets fixed! https://github.com/w3c/deviceorientation/issues/57

Does AFrame VR offer a fallback interaction model for desktop users and mobile users who choose not to allow sensor access?

@geoffraygaren Yes, on desktop you can use mouse / keyboard to move the camera and touch on mobile.

Current conversation about spec:
https://github.com/w3c/deviceorientation/issues/57

Also disabled now in Chrome. Console log on Chrome m74 for Android:

The `devicemotion` event is deprecated on insecure origins and will be removed in M76, around July 2019. Event handlers can still be registered but are no longer invoked since M74, around April 2019. See https://www.chromestatus.com/feature/5688035094036480 for more details.

8th wall does this:
IMG_6547

@vin-ni thanks for sharing. We have this conversation going on: https://github.com/aframevr/aframe/issues/4149

Do you know how 8th wall checks for devicemotion presence?

For the record:

iOS now requires both enable device motion manually:

Settings -> Safari -> Motion & Orientation access

and page has to be served over https

Android also disables devicemotion. Reference to discussion: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/5yqfAXibz1I/wiLKUPLwDwAJ

mmmm, is this supposed to be the standard? Not device motion anymore?

No devicemotion events enabled by default anymore for Chrome and Safari. The user has to enable manually. API is standard but https enforcement or shipping it enabled is a particular decision of each browser vendor.

Are there any alternatives? Or any roadpath?
this kind of kill Aframe on mobile.

It's an unfortunate decision and we cannot do anything on the A-Frame side. Only way to address is showing message to the user to enable the API on settings. More info https://github.com/aframevr/aframe/issues/4149

Looks like the API for requesting permission to receive device motion is available on IOS 13 developer beta. https://github.com/w3c/deviceorientation/issues/57#issuecomment-498417027

Thanks for the update. For reference the API is DeviceOrientationEvent.requestPermission

Unfortunately, on iPadOS, there is no such option of device orientation and motion access in the settings menu. Device orientation is not working in beta 1 on iPad Pro 2017 release.

@chetu3319 there’s a permissions API now that applications have to invoke DeviceOrientationEvent.requestPermission
and deviceorientation events wont’t fire when the devices is laying on a flat surface.

Hello, I just started following this project again recently, and I'm highly interested in contributing and this seemed like some low hanging technical fruit to help me become familiar with this project. Looking forward to any feedback you may have for my PR, and any suggestions as well.

Thanks

Slowly but surely, this security and privacy bullshit is killing off technology as we know it. Maybe it should just stop?

Once iOS 13 ships things will be back to normal. A-Frame will be able to
request access to devicemotion API without any manual steps. https will be
required though

On Tue, Jul 2, 2019 at 6:13 PM SevenSystems notifications@github.com
wrote:

Slowly but surely, this security and privacy bullshit is killing off
technology as we know it. Maybe it should just stop?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aframevr/aframe/issues/3976?email_source=notifications&email_token=AAAJTLTNWO5DXAWZ6M4HUFTP5P4MXA5CNFSM4GS7EUI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZC65ZQ#issuecomment-507899622,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAJTLQFKE4XGIG36UE263LP5P4MXANCNFSM4GS7EUIQ
.

iOS 13 is out and A frame isn’t requesting devicemotion API access on 0.9.2

Just to make sure, is this still a problem? I wasn't able to make the examples on aframe.io work in Safari.

It still seems to be a problem from what I can see, and my iOS is 13.1.3

I think we can call this closed?

Correct 🎖 thanks

Was this page helpful?
0 / 5 - 0 ratings

Related issues

RangerMauve picture RangerMauve  Â·  4Comments

jgbarah picture jgbarah  Â·  4Comments

micahnut picture micahnut  Â·  5Comments

minchnew picture minchnew  Â·  3Comments

jonikorpi picture jonikorpi  Â·  4Comments