Accelerometer data in iOS 12.2 - 13

[rvegele]

Nature of issue?

• Found a bug
• Existing feature enhancement
• New feature request

Most appropriate sub-area of p5.js?

• Color
• Core/Environment/Rendering
• Data
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Other (iOS platform in particular)

Which platform were you using when you encountered this?

• Mobile/Tablet (touch devices)
• Desktop/Laptop
• Others (specify if possible)

Details about the bug:

• p5.js version: ...
• Web browser and version: iOS Safari
• Operating System: iOS 12.2 and above
• Steps to reproduce this: None of the accelerometer features work under iOS 13 and in >12.2 one needs to get permission.
  https://www.macrumors.com/2019/02/04/ios-12-2-safari-motion-orientation-access-toggle/

[welcome]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, be sure to follow the issue template if you haven't already.

[stalgiag]

It is possible that a sketch can request permission to receive device orientation events. Here is an issue that is tracking the release of this feature. The support is going to be spotty and unpredictable for a while it seems.

It might be best to add a note stating that "Safari is not fully supported" in the docs for the relevant functions.

[limzykenneth]

The accelerometer is working for me on iPhone SE iOS 13.1, and oddly enough I can't find the toggle that turns access to it on and off.

[limzykenneth]

Ok, I was actually using Firefox on iOS as I thought the access is implemented across the webkit views but upon trying on Safari, it doesn't work anymore.

[elmariocarlos]

My team and I are having the same issues; we had a functional working game before iOS 13, and we have followed steps to request DeviceMotion permissions. The approach works using Safari, but not when navigating using WKWebViews. We really need more clarity on this.

@cdumez related to the same issue where I tagged you some minutes ago.

[limzykenneth]

Is there any guidance from Apple regarding requesting permissions on WKWebViews? Firefox on iOS is basically wrapping a WKWebViews as far as I know so it should be possible to implement it in code directly.

[elmariocarlos]

@limzykenneth not a real guidance, but there are documentas and sites here and there. We have followed this:

https://medium.com/flawless-app-stories/how-to-request-device-motion-and-orientation-permission-in-ios-13-74fc9d6cd140

It works for Safari, but not when using WKWebView. So this is basically the quickl approach to solve the problem on the default experience, which is navigating with Safari.

For the WebView, I think it has to do more with creating a specific controller to catch this and then push the dialog to accept/deny the permissions. But then this means WkWebView should have something to push the same dialog as Safri, but so far nothing out there that I have been able to test othar than the above, which is basically the same as nothing :(

[elmariocarlos]

@limzykenneth not a real guidance, but there are documentas and sites here and there. We have followed this:

https://medium.com/flawless-app-stories/how-to-request-device-motion-and-orientation-permission-in-ios-13-74fc9d6cd140

It works for Safari, but not when using WKWebView. So this is basically the quickl approach to solve the problem on the default experience, which is navigating with Safari.

For the WebView, I think it has to do more with creating a specific controller to catch this and then push the dialog to accept/deny the permissions. But then this means WkWebView should have something to push the same dialog as Safri, but so far nothing out there that I have been able to test othar than the above, which is basically the same as nothing :(

I just noticed I had another reply in this thread:

w3c/deviceorientation#57 (comment)

@limzykenneth

[lmccart]

I was just looking into this. If this is Apple's stance going forward, we will need to consider adding a function that requests permission for motion and orientation. It needs to be triggered on user gesture. Something like enableMotion() or similar?

[elmariocarlos]

Well I have opened a bug listing in bugs.webkit.org : https://bugs.webkit.org/show_bug.cgi?id=203287

Basically what has been discussed so far is that a WkWebView should be OK to get direct access to sensors, but so far I haven't been able to achieve this on iOS 13 because of some reason. The WebKit team has replied with the use of a iOS native app called "WebView" that based on that implementation, there is proof WkWebView does provide direct access to sensors.

In my case the strugle is to identify if it's because it's a native implementation, or if it's an error due to the plugins we are using to get this feature working from a Flutter project that ends in an IPA.

If you would like to jump in the disucssion at webkit.org just follow the link =) @lmccart

[limzykenneth]

@elmariocarlos For your particular case I think you will have to sort it out between flutter, webkit and your own code and there's not much we can do here as the behaviour described by Chris Dumez in the webkit issue is consistent with the behaviour I've observed so far, with Firefox on iOS switching to a behaviour inline with Safari, and WkWebView not requiring user interaction nor permission.

For an example that work across all views (Safari and WkWebView), have a look at this one from three.js

@lmccart The whole API is technically still in a draft state by the W3C so it may still change but it seems the major browsers are going to move this behind user interaction and requestPermission. We can handle requestPermission in the codebase seemlessly (see here from three.js), but the user interaction is the same problem as the audio volume/autoplay policy that audio and video both had. Can we perhaps put these behind a unified optional gesture request that a user can choose to not implement if they didn't need it? No particular idea for implementation yet, just an idea.

[elmariocarlos]

Hi @limzykenneth yes that is precisely what I mentioned. The scenario is still relevant, because if all this would be really as straightforward as mentioned it should work regardelss. There must be some other things that are affecting how the standard must be implemented.

Example, it would be good to have source code for a base iOS app opening a wkwebview and then making the calls to open the URL and working. Just opening another app (with understanding how that native implementation is using the wkwebview kit), isn't a real proper test.

[cdumez]

You may be hitting the following bug:
https://bugs.webkit.org/show_bug.cgi?id=203287

The workaround is the set a WKUIDelegate on the WKWebView in the meantime.

[elmariocarlos]

Hi @cdumez sorry to take so much time to get back on this. Our project had a sudden diversion to get another core feature fixed.

@Alucherdi is currently codign some tests to run on our Mac as soon as it's back from shop :(. I'll let you know when they are complete.

[muaviya]

You may be hitting the following bug:
https://bugs.webkit.org/show_bug.cgi?id=203287

The workaround is the set a WKUIDelegate on the WKWebView in the meantime.

it's work for me, thanks

[montoyamoraga]

since there was a workaround that worked, i am closing this issue, feel free to reopen if needed.