Thanks for doing this.. So far the code approach looks sensible. I haven't been able to test it on device yet.

Update on this: I found that iPad works for Firefox and Safari: in both cases, the applications had Desktop Version Requested. You either needed to set the preference in your preferences, or select the aA icon in the left of the location for Safari; or the three dots on the right side of Firefox, to Request Mobile Site. That means that what I have done is working across the target browsers on iOS and iPad browsers; I believe that it will also work on Android devices as well (not tested on many). The controller is in the bottom left of the screen to ask permission. For android devices, you will not need to select it.

https://planetkevin.com/aframe/examples/showcase/device-motion-permission/a.html

The last thing remaining from development perspective is getting past Travis. It is erring out on code that was written before me which I do not believe my code impacts. Is there something I am not understanding on this?

Matching Travis requirements, pulling out identified linting errors. Last big remaining item, making the modal screen attractive. Currently, Cancel and Continue buttons are functional. My idea: a Built with Aframe logo and wording that tells users that permission is required for device motion. I can continue with this, or if anyone else has an idea of what can be included here graphically, that could also be helpful.

Thanks for all the hard work! It's coming along pretty well. I made a few style changes to match linter style, eslint-disable should not be necessary. As mentioned the only remaining work is styling the dialog. I would keep it as unbranded as possible. We can reuse the rotation modal dialog gray background add cancel, accept buttons and some text: This VR site requires access to your sensors. Press accept to allow

Just about complete. Has new modal screen; will add clickable to it later today (November 14th)

Great job! Thanks for sticking with it. I made a few change suggestions. This is getting really close.

Just pushed latest updates; with comments and most all critiques included.

thanks @KevinEverywhere! FYI I tested out your demo on Android 9 Chrome browser (& also on iOS 13 Safari), works well!

Thanks a lot everybody for the hard work and the testing. I adjusted a bit the code style to the rest of A-Frame, removed some redundant logic and tweaked the visual style of the modal dialog. I tested on iOS 13.2 on iPhone X and Chrome m78 on a Pixel 3 with Android 10. I don't have an iPad handy at the moment to test with. If you can let me know if it works and what you think about the dialog it'll be appreciated. The PR is almost ready. We only need docs for the device-motion-permission-ui component and some basic test coverage.

@dmarcos , will you want me to complete this: the readme, for instance. Also, I had one last test that is not included here. iPad OS 13 defaults to Request Desktop Website. A person with an iPad would not know that this fails without having feedback. my solution is below. I tested on a number of devices and operating systems, desktop and mobile. This took over 40 hours of time to resolve something that kept aframe content from being functional on iOS/iPad 13 devices. Thanks.

isMobile: function() {
return /iPhone|iPad|iPod|Android/i.test(navigator.userAgent);
},
grantedDeviceMotion: function () {
if (!this.isMobile()) {
alert('You appear to have a mobile device, but you may have requested a Desktop Website. Check the location bar of your browser and ensure you are requesting the Mobile Website.');
} else {
...
}

The other place this would be used is after the window.orientation check:

  // This is for desktop browsers and those who cancel or reject
  if( this.isMobile() ){
    alert('You appear to have a mobile device, but you may have requested a Desktop Website. Check the location bar of your browser and ensure you are requesting the Mobile Website.');
  } else {
    this.remove();
  }

Adding iPad to isMobile function I think will result in tablets entering stereo cardboard mode vs. full screen that I don't think we want. Mobile devices requesting desktop websites make things messier than they were 😄 Trying to find the simpler set of conditions that also preserve previous functionality while also avoiding isMobile duplicated logic. I'll get a hold of an iPad with iOS 13 later in the day and test the PR. Thanks for the help.

@dmarcos am grabbing my iPad now and cloning the PR to test

@subelsky and @dmarcos; if anyone can post the output file for testing, that would be great. If either you or anyone else can compare what already is up at the URL below to work on all target browser/devices; I think that the cardboard/fullscreen worry will be mooted. Also, you can test your iPhone against this. Currently, if your iPhone is set to Desktop Website Requested, you do not have feedback to let you know. What I have is reverse compatible and covers iOS/iPad and Android.

https://planetkevin.com/aframe/examples/showcase/device-motion-permission/b.html

@KevinEverywhere here's what I did:

HOST=0.0.0.0 npm run dev
ngrok http 9000

that gave me an SSL URL like https://xxxx446f.ngrok.io/ which I visited on the iPad. Still testing

attached is the build file which I produced via: npm run build:
aframe.js.gz

hope that helps! this feature is going to be awesome for a couple of projects, PSYCHED

I changed the mobile device requesting desktop site condition to what @KevinEverywhere suggested and It works on an iPhone X with iOS 13 when requesting a desktop site. Also works on Android m78 / Pixel 3 / Android 10 when requesting mobile and desktop sites. All looks good. I'm going to write some tests and docs and I'll merge later in the day. We can adjust edge cases later if needed. Thanks all for your help.

Looks great, @dmarcos; checked it on iPad Pro with iPad 13 installed with Mobile and Desktop Website Request and it worked as expected on both. The build from 71009c4 is the aframe-aframe.js file used here:

https://planetkevin.com/aframe/examples/showcase/device-motion-permission/c.html

Documented and tested! Shipping 🚢 Thanks everybody for the hard work.

@dmarcos : Is this feature coming with 0.9.3 on 6th december?

Yes but you can use it today via master builds: https://cdn.jsdelivr.net/gh/aframevr/aframe@934b8d358a2c458efdc8d65fcb6946f7303f0b51/dist/aframe-master.min.js

Let us know if you have any issues

Works very well! Is there any chance this will be included in Aframe 0.8.2? Since the breaking change of a-animation in V0.9.2 my code does not work in that version, and I see no real possiblity to upgrade it in the near future. I suspect a lot of people will stay with 0.8.2 for the coming months/years because of this breaking chance

@tommensink Unfortunately, We don’t patch previous releases. It’s not sustainable to maintain multiple versions. Can you elaborate on the breaking change that it’s preventing to upgrade to 0.9.2? a-animation got replaced by the animation component but the API is the same. It should be easy to upgrade. I recommend testing master now in anticipation of 0.9.3. Browsers are deprecating WebVR in favor of WebXR and outdated experiences will stop working in VR mode.

Thanks, and I understand. It is just that I use a-animation a lot and would not know where to begin to replace it in my code, since I use a nested structure with some sort of animation sequencer that I made. You can see it in https://hh-webar.firebaseapp.com/Presentation_2019-01-26/. (Just let the head rotate on your screen to see the different transparancy sequences kicking in).

My personal opinion is that moves from Apple like this motion-issue (which of course also can be understood, but nevertheless) and breaking Aframe changes will throw it back for some years to be adopted by the professional market. I for one will do the major serious AR/VR projects in Unity and use Aframe only for gadgets like dancing business cards

I hope I don't hijack this thread for this discussion too much, but one last thing then: You should hear me about breaking changes in Unity or their horrific tight integration of libraries like Vuforia (who break the API every release). But having said that, I am a full time AR developer, make dozens of apps as lead developer in four AR startups, including one of the first to do actual brain surgery with a HoloLens. So I have to choose the most appropriate and stable Entity Component Framework regularly. Funny moves like this one from Apple (and we had something similar on Android beginning of the year which requires the user to change a setting jeromeetienne/AR.js#369 (comment)) is one reason to choose another platform that will keep running no matter the OS change. An issue like this means that I will judge again in one or two years for Aframe in critical apps, hence my "Aframe is thrown back years" by this. Also if the Aframe community decides they should make breaking changes to the API like a-animation, then this does not work in favour of this decision. Just my opinion, do think the major companies have similar considerations, but cannot speak for them.

The actual main issue here I think is that Apple and Google will never break their normal apps, or they issue warnings in ample time for developers to change their code, yet they make WebXR changes to their browsers without any warning. This is a vicious circle: when AFrame and WebXR become more important, they will be more cautious too. But for this we have to make more apps in AFrame and WebXR.

But I think you guys are awesome, this solution is great Kevin (I applied your first one which works with V0.8.2) and I always support AFrame in discussions and presentations as THE best open platform.