Thanks for fixing this one Klaus, The 1.20.10 wakelock fix is working ok for me on new tours using panotour, on an iPhone 6s Alexander, but the example on the krpano site did still timeout/dim, I did clear the cache. Some of the tours I've updated the viewer files of on my own site take a few days to show the update versions, could that be the same for the krpano ones maybe? Works perfectly on new built tours for sure.
Best regards,
Rob
Thanks for fixing this one Klaus, The 1.20.10 wakelock fix is working ok for me on new tours using panotour, on an iPhone 6s Alexander, but the example on the krpano site did still timeout/dim, I did clear the cache. Some of the tours I've updated the viewer files of on my own site take a few days to show the update versions, could that be the same for the krpano ones maybe? Works perfectly on new built tours for sure.
Best regards,
Rob
Hi Rob, thanks for replying! I can confirm that it is fixed using the latest build, however, it seems to only work when starting VR through the skin toolbar button, not any custom hotspot using onclick="webvr.enterVR();" I can't figure out why that would be but I'll keep testing and post an update if I manage to resolve it.
Thanks!
Update: I was wrong, using a custom hotspot with onclick="webvr.enterVR();" works fine. It seems you still need to add in a window.DeviceMotionEvent.requestPermission() for this to work on the first load of a tour as reported here: https://krpano.com/forum/wbb/inde…otify#post84314
New Problem: Videohotspots in webvr... I know these are plagued with issues. But my project includes a video hotspot in VR. When the user taps to play the video on iOS device (iPhone 6S in this case) then the video starts to play but it knocks out the iOS wakelock fix (which I presume is a video file being played in the background)?
Klaus - Is there a way to call or restart the wakelock fix once my other video hotspot is either closed, paused or stopped?
Thanks in advance.
Upgraded to iOS 15.0.1 on my iPhone 6s and unfortunately the VR wakelock doesn't seem to work on first load of a tour when clicking allow access motion and orientation now, but if you load the same tour again or any others from the same server it works fine, just the initial load of VR mode the screen dims/timesout. This is the same for the KRpano examples too. What version of iOS are you running Alexander, is it the same for you or not?
Hi,
the VR wakelock doesn't seem to work on first load of a tour when clicking allow access motion and orientation now, but if you load the same tour again or any others from the same server it works fine, just the initial load of VR mode the screen dims/timesout.
This makes sense - the user permission-asking dialog probably conflicts with the touch user-interaction that is required to start playing the internal wake-lock video. I will change that order - first start the wakelock, then request the gyro permission. Then this case should also work. Will report when there is a new version with that.
Best regards,
Klaus
Hi,
This makes sense - the user permission-asking dialog probably conflicts with the touch user-interaction that is required to start playing the internal wake-lock video. I will change that order - first start the wakelock, then request the gyro permission. Then this case should also work. Will report when there is a new version with that.Best regards,
Klaus
Hi Klaus, thank you for your response. But what is the code to start / restart the wakelock? (Sorry if I am repeatnig myself...) I have video distorted hotspots in my project so when the user taps to play the video on iOS device then the video starts to play but it knocks out the iOS wakelock fix (which I presume is a video file being played in the background)?
Is there a way to call or restart the wakelock fix once my other video hotspot is either closed, paused or stopped?
Thanks in advance.
Thanks for sorting this one Klaus, it's much appreciated - glad you were able to identify the problem easily. Look forward to the revised version.
Best regards,
Rob
Hi All,
I appreciate Klaus is currently working on a iOS 15 fix to the wakelock bugs reported in this thread. However, I thought I would create a test and example to help make the bugs clear - and also show the fixes I have tried - to try and help others.
Apologies for the long post, I figured explaining the issue in detail might help others. And apologies if I am repeating the issue I mentioned in my previous post, again I thought extra details and examples might help.
The main bug which I cannot solve is the Wakelock fix for iOS (15) devices which works (using the below fix) until a user plays a video - then the wakelock is stopped and I cannot see anyway of either restarting it or having it run in the background alongside other videos?
Here’s what I am trying to achieve:
User loads the tour, presses the ‘VR' icon with their finger to launch VR. The user then navigates the tour and the screen does not timeout / fade or go to black, from the very first time they load of the tour (currently this only works after a refresh on iOS devices). When the users gets to a pano with a video hotspot (i.e. pano 2 or 3 in the below examples), they can use gaze / onclick to play the video / or it automatically starts without the need to physically touch the screen. This should work with more than 1 video hotspot in the tour. The videos will have audio so muting is not an option. The key feature / bug here is: when the user plays a video, the wakelock hack stops. Is there a way of making the wakelock hack remain active and is not stopped either during the video hotspot plays, or after the video hotspot ends?
Here’s a demo I have created with the above features using version 1.20.10 (2021-10-01) Accessing this tour on an iPhone 6S running iOS 15 in either Chrome (version 86.0.4240.93) or Safari (15.0) has the following bugs:
Demo Link: https://northeast360.co.uk/video-wakelock-issue/
Here’s a list of fixes I have tried with corresponding code / demos, hopefully these might help others:
Bug 1 & 2 fix
Klaus mentioned there being an issue with the order of the permissions earlier in this thread, so this may well be fixed in the next release. Until then, I found the following workaround.
Using javascript, you can force the DeviceMotionEvent.requestPermission before the user taps the VR icon. To do this, add the following code to the tour.html file:
In the <head> the below code includes the CSS to style the pop up permission box.
<style>
.DeviceMotionRequestBanner {
position: absolute;
left: 0;
right: 0;
margin-left: auto;
margin-right: auto;
width:300px;
height:120px;
top:40%;
background-color: #ef2d5e;
padding: 20px;
color: #fff;
font-family: Open Sans, Helvetica, Arial, sans-serif;
box-shadow: 0 3px 6px rgba(0,0,0,0.16), 0 3px 6px rgba(0,0,0,0.23);
z-index:99;
display:none;
}
.DeviceMotionRequestBanner > h3 {
font-size: 28px;
margin: 0;
font-size: 28px;
font-weight: 300;
line-height: 1.2;
letter-spacing: -.05rem;
}
.DeviceMotionRequestBanner > p {
font-size: 1.1rem;
}
.DeviceMotionRequestBanner > button {
background-color: #fff;
color: #000;
padding: 8px 30px;
text-transform: uppercase;
border: none;
position: absolute;
left: 0;
right: 0;
margin-left: auto;
margin-right: auto;
width: 100px;
}
.DeviceMotionRequestBanner > button:hover {
color: #ef2d5e;
}
.DeviceMotionRequestBanner > a {
color: #fff;
margin-left: 25px;
}
</style>
<script>
//script for ios wakelock issue
window.onload = function () {
// Check if is IOS when page loads.
if ( window.DeviceMotionEvent && typeof window.DeviceMotionEvent.requestPermission === 'function' ){
// Everything here is just a lazy banner. You can do the banner your way.
const banner = document.createElement('div')
banner.innerHTML = `<div id="DeviceMotionRequestBannerID" class="DeviceMotionRequestBanner" style="display:block;"><p>This app requires you to enable the DeviceMotion event on your device.</p><button>Enable</button></div>`
banner.onclick = ClickRequestDeviceMotionEvent // You NEED to bind the function into a onClick event. An artificial 'onClick' will NOT work.
document.querySelector('body').appendChild(banner)
}
}
function ClickRequestDeviceMotionEvent () {
document.getElementById('DeviceMotionRequestBannerID').style.display='none';
window.DeviceMotionEvent.requestPermission()
.then(response => {
if (response === 'granted') {
window.addEventListener('devicemotion',
() => { console.log('DeviceMotion permissions granted.') },
(e) => { throw e }
)} else {
console.log('DeviceMotion permissions not granted.')
}
})
.catch(e => {
console.error(e)
})
}
</script>Demo Link: https://northeast360.co.uk/video-wakelock-issue-fix/
Now, when the user loads the tour on iOS devices, a pop up will show asking them to enable devicemotion permissions. This will allow wakelock to work from the first load, not requiring a refresh as described above in bug 1. If you gaze (onclick) to move to the next pano and then gaze (onclick) on the youtube icon. Then wait around 20 seconds or so (I presume for the video to preload or something?) you can get the video to play without the user needing to touch the screen. It might take a few gaze (onclicks) to get it to work, but it does eventually play (each onclick pauses / unpauses the video). So in theory, whilst it's very glitchy and for some reason the preload is taking a long time? The video will auto play without needing the user to touch the screen.
However, when the video hotspot plays, the wakelock fix is stopped. I cannot see anyway of restarting the wakelock fix or making sure it remains playing whilst another video is also playing?
Klaus can you help?!
Hi
Since i use 1.20.10 my tours crash the oculus quest 2 browser as soon as i clic on enter vr
any idea on how i can debug this?
>>>> OK SORRY THE OCULUS UPDATE WAS NEEDED HERE :)
thanks
Hi Klaus,
Any Christmas gift to krpano coders from you? :)
Merry christmas to you.
Hi Klaus,
Any Christmas gift to krpano coders from you? :)
You should know by now that Santa NEVER is giving inside-information about confidential cases before they are publicly released.
In holland we have saying: " Children who ask questions are skipped. "
You should know by now that Santa NEVER is giving inside-information about confidential cases before they are publicly released.
In holland we have saying: " Children who ask questions are skipped. "
g inside-information about confidential cases before they are publicly released.
In holland we have saying: " Children who ask questions are skipped. "
Don’t have an account yet? Register yourself now and be a part of our community!
