|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
[Affected versions]: Fx 55.0b12 [Affected platforms]: Windows 10 x64 + Oculus Rift [Steps to reproduce]: 1. Close Oculus runtime if it's open 2. Put the headset on (the Oculus Home will start automatically) or open the Oculus application manually and then put the headset on. Wait for the Oculus Home environment to start presenting. 3. Open Firefox and load any WebVR content, for instance: https://webvr.info/samples/03-vr-presentation.html 4. Click on Enter VR [Expected result]: Content presents in the headset. [Actual result]: The Oculus Home remains in the headset while in the browser I can see the WebVR content rendered with proper head tracking.
It also affects Firefox Nightly 56.0a1 (2017-07-25) (64-bit)
I changed dom.vr.oculus.quit.timeout to 0 but it does not seem to make any difference.
My dom.vr.oculus.quit.timeout is 30000. It happens to me as well. I click the enter vr button, but I would see a black image or still be at Oculus home at 56.0a1 (2017-07-25)
With an older NVidia driver (382.05), I was able to reproduce, but with a slightly different STR: - Make sure no Firefox.exe or Nightly.exe processes are running - Start Oculus Home - Start Firefox - Start a WebVR site (I used https://webvr.info/samples/04-simple-mirroring.html) - Click the Enter VR button - Close Oculus Home (Do not exit VR first) - Start Oculus Home again (must be within 30 seconds) - Refresh the page - Page reports that no HMD's are present (We purposefully don't allow pages to start Oculus runtimes back up until 30 seconds after Oculus us shut down in the middle of WebVR, so we can allow the processes to close during Oculus automated runtime updates) - Wait 30 seconds - Refresh the page - The headset is detected again - Click "Enter VR" - Expected behavior: Content is displayed in the headset - Actual behavior: Content is not displayed in the headset, but the mirror image shows tracking. Framerate is low at ~15 fps. Connecting a debugger to the process indicates that the ovr_submitframe call is returning 1000, indicating that the content is hidden. I haven't been able to repro this after updating to the latest NVidia driver (384.94 at this time) Please note that the 15fps is due to the throttling mechanism in Firefox's WebVR implementation that kicks in when content is presenting but blurred / hidden by other things in the headset. This is normal behavior if the content was actually hidden behind an interstitial such as the Oculus Health and Safety Warning or system menu.
[Affected versions]: FF 55.0b12 and 56.0a1 (2017-07-25) [Affected platforms]: Windows 10 x64 + Oculus Rift. NVidia driver (384.94) [Steps to reproduce]: 1. Open Oculus runtime if it's closed. 2. Put the headset on. Wait for the Oculus Home environment to start presenting. 3. Open Firefox and load any WebVR content, for instance: https://aframe.io/a-painter/ 4. Click on Enter VR [Expected result]: Content presents in the headset. [Actual result]: The Oculus Home remains in the headset while in the browser I can see the WebVR content rendered with proper head tracking. However, if I close the Oculus runtime, then opening FF and asking it go to a WebVR page. It works properly.
I was able to reproduce on 56.0a1 (2017-07-26), Windows 10 x64. Both with Nvidia drivers 384.94 and older 382.66 [STR] 1. Put my headset, it will open Oculus home 2. Open Firefox and go to any WebVR content 3. Click Enter VR [Expected result]: Content presents in the headset [Actual result]: Oculus home still in the headset. While the browser seems to freeze and goes everything to white. I can't see anything and as I move the mouse around the browser's window the menu bar and bookmarks goes also white, but I can click stil click on the "invisible" items.
After changing "layers.mlgpu.dev-enabled" to false, I don't get the freeze to white, but the result is the same the webvr content doesn't show up on the headset and it's still presenting oculus home correctly.
I've been using the following steps to enter VR correctly from webvr content, but if the Oculus home is closed after that, it will block the page and the headset will go to black [STR] - Launch oculus home - Launch firefox - Close oculus home - Enter VR - (Oculus app will launch in the background but it won't present oculus home) - (If you exit VR the headset will goes to black, if you enter VR again, it will show the webvr content as expected). - Close oculus home [Expected result]: Content will keep presenting on the headset [Actual result]: Headset goes to black, and page freezes
status-firefox57: --- → affected
Priority: -- → P1
It still happens to me intermittently.
I have checked ovr_SubmitFrame() always returns ovrSuccess even though we can't see the content in Oculus Rift. I am curious if after Bug 1381085 is landed, it could solve this problem.
It can be resolved by replacing the init flag, (ovrInit_RequestVersion | ovrInit_MixedRendering) with ovrInit_RequestVersion. But, the drawback is after we exit from the present mode, our HMD will be black until closing Firefox. We still can use Touch back to Oculus Home but Firefox will be force to deactivate from Oculus. Kip, do you think we should give a fix like this?
(In reply to Daosheng Mu[:daoshengmu] from comment #11) > It can be resolved by replacing the init flag, (ovrInit_RequestVersion | > ovrInit_MixedRendering) with ovrInit_RequestVersion. > > But, the drawback is after we exit from the present mode, our HMD will be > black until closing Firefox. We still can use Touch back to Oculus Home but > Firefox will be force to deactivate from Oculus. > > Kip, do you think we should give a fix like this? We need to keep the ovrInit_MixedRendering flag to ensure that the Oculus runtime behaves as needed for the browser use case. In particular, this prevents Oculus home and the Oculus compositor from spinning up when users hit a site that probes for webvr hardware. We are working with Oculus on the issue and they are helping to investigate the issue with the missing/occluded presentations. It's possible that an update to the Oculus runtime could correct the problem. On our end, we should double-check that we are tearing down and re-creating the Oculus session every time the VR presentation is started and stopped. Also, we need to double-check that the ovrInit_Invisible flag is set correctly each time the session is re-created. I'll be sure to follow up with our contacts at Oculus now that the FF57 merge date activity is settling down.
I have sent details about our usage of the Oculus API to the Oculus SDK team for review and will continue exploring on our end.
It seems to be resolved after Bug 1410493 land, I just pull the latest m-c and can't reproduce it again...
(In reply to Daosheng Mu[:daoshengmu] from comment #14) > It seems to be resolved after Bug 1410493 land, I just pull the latest m-c > and can't reproduce it again... It was harder to reproduce, but I was able to confirm it still happens after a few tries. Once Bug 1411055 and Bug 1407423 have landed, I'll follow up again with Oculus.
Depends on: 1407423
Seems likely that 58 is also affected. Too late to fix in 57 though.
status-firefox57: affected → wontfix
status-firefox58: --- → affected
Oculus Dash has just been released to Beta so we can fine-tune the prefs and adjust the session handling code to work best in the latest runtime.
Comment on attachment 8935586 [details] Bug 1384279 - Oculus Rift Core 2.0 Adjustments https://reviewboard.mozilla.org/r/206470/#review212158 r=me. I am curious if it would fix the problem of Oculus Rift can't enter the present mode when Oculus home has already launched after these changes.
Attachment #8935586 - Flags: review?(dmu) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/50a8780085a0 Oculus Rift Core 2.0 Adjustments r=daoshengmu
Status: NEW → RESOLVED
Last Resolved: 3 months ago
status-firefox59: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Too late for Beta58. Mark 58 won't fix.
status-firefox58: affected → wontfix
QA Contact: cristian.comorasu
Sorry for the long pause. I verified this issue using Oculus rift on Fx 59.0b9 and Fx 60.0a1(build ID: 20180213100127). I can confirm this issue is no longer reproducible.
Status: RESOLVED → VERIFIED
status-firefox59: fixed → verified
You need to log in before you can comment on or make changes to this bug.