1454204 - WebVR doesn't present in Vive on Mac OS

Status: RESOLVED FIXED

(Core :: WebVR, defect)

Description

[Ian Gilman [:iangilman]]

I'm running Mac OS 10.13.4 (17E199) with Steam VR beta version 1523560849 (built April 12, 2018) and Firefox Nightly 61.0a1 (2018-04-15) (64-bit). I can run Blobby Tennis from Steam, and I can run VR projects created in Unity 2018.1.0b13; those both present in the Vive without trouble and with smooth frame rate. WebVR in the Firefox Nightly, however, does not present in the Vive at all.

Repro steps:

1. Start Steam VR
2. Open Firefox Nightly
3. Go to https://webvr.info/samples/03-vr-presentation.html
4. Hit the "Enter VR" button in the lower right

Expected:

The VR scene would be shown in the Vive headset.

Actual result:

The headset remains in the default Vive "white room". The display in the browser updates to a split screen but otherwise remains unchanged. The FPS meter drops to one or zero.

Observations:

Some communication between the browser and the headset appears to be happening. For instance, when first loading the page in the browser, the scene shows up in the browser oriented to match the headset (straight on if the headset is sitting on a table, tilted if the headset is tilted, etc.). However, no additional changes to the headset are picked up (until next time you load the page). Also, if the headset has fallen asleep (the display has gone dim due to lack of activity), and you load the webpage, the display wakes up (even though it stays in the white room).

Basically it appears we get a single frame of connection and then go back to disconnected.

Interestingly, if you then refresh the webpage, you are informed "WebVR supported, but no VRDisplays found." You have to actually restart the browser to even get the minimal (single frame) of connection you got before.

I've tried a number of other WebVR pages and they all present more or less the same symptoms.

Comment 1

[anthony.scavarelli]

I have seen the same symptoms. Actually I had the exact same scenario happen before I updated to 10.13.4. Now the Vive no longer communicates at all (no first frame on mirrored display - has never displayed in headset). It just doesn't recognize the Vive connected at all. However, as above, I can build with the MacVR Unity build and see the default grey room.

- Mac OSX 10.13.4
- SteamVR Beta
- Firefox Nightly
- Akito Node w/ AMD Radeon 580 (Not a Sonnet yes, but seems to work fine in every other respect).
- The entire setup works perfectly find in Windows Bootcamp

EDIT: Just noticed a SteamVR update. Will try again tonight.

Comment 2

[pascal.bayer]

Reproducible on the following setup:

- MacBookPro 14,3 
- macOS 10.13.4 (17E199)
- GPU Radeon Pro 560
- eGPU GeForce GTX 1060 (via Sonnet eGFX Breakaway Box 550)
- Vive
- Vive Pro
- Steam VR Beta - 2018-04-12 (1523560849)
- Firefox Nightly - 61.0a1 (2018-04-15) (64-bit)

Using the same setup on Windows 10 with Bootcamp works fine (most of the times).


Observations on Windows that might be related:

If SteamVR isn't launched on the same monitor the VR headset is mounted to (different outputs but same GPU), only motion tracking works on FF Nightly for Windows, but no WebVR stream is available only "default room" as on macOS. So maybe not picking up the correct display on macOS?

Comment 3

[Ian Gilman [:iangilman]]

I know this combination (Firefox/Vive/Mac OS) has worked in the past. As far as identifying when the breakage happened, there's this tweet that suggests it started with 61.0a1(20180314102135):

https://twitter.com/VRonMac/status/975901108378972160

Of course we don't know if the change happened in Firefox or Steam or Mac OS or some combination. Still, having a sense for the timing might be a useful clue.

Comment 4

[Ian Gilman [:iangilman]]

It occurred to me I could try an earlier Nightly, from before the breakage was first reported, to see if that would work. I tried 60.0a1 (2018-03-01) (64-bit):

https://download-origin.cdn.mozilla.net/pub/firefox/nightly/2018/03/2018-03-01-02-47-24-mozilla-central/firefox-60.0a1.en-US.mac.dmg

… which would have been a couple weeks before the tweet above. I got the same symptoms.

I then tried 60.0a1 (2018-02-01) (64-bit) from a month before:

https://download-origin.cdn.mozilla.net/pub/firefox/nightly/2018/02/2018-02-01-10-03-26-mozilla-central/firefox-60.0a1.en-US.mac.dmg

It doesn't work completely there, but it is different! Once you hit "enter VR" the scene in the browser responds properly to the position and orientation of the headset. The headset doesn't show the scene, but it does switch from the usual "white room" to an almost identical "black room" with a white square on the floor. Meanwhile the SteamVR status window says "(unresponsive) Firefox".

I then tried 59.0a1 (2018-01-01) (64-bit):

https://download-origin.cdn.mozilla.net/pub/firefox/nightly/2018/01/2018-01-01-10-04-04-mozilla-central/firefox-59.0a1.en-US.mac.dmg

Sure enough, it works! When you hit "enter VR" the browser shows "put on your headset now" and the scene plays in the headset. The SteamVR status window just says "Firefox". Everything is good.

So… It appears that something happened in the Firefox code between January 1 and now that broke the Mac WebVR support. This means the breakage isn't in Mac OS or SteamVR. I hope this helps track down the solution!

Comment 5

[anthony.scavarelli]

Nice find, that version works for me as well.

Comment 6

[:kip (Kearwood Gilbert)]

Thanks for narrowing the regression range.  I'm investigating this now, and hope to have a fix soon.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

WebVR is shipping for OSX with Fx60 next week, but we're already building RC builds for it :(. Seems highly unlikely we're going to have a fix ready in time, but let's keep this bug on the radar just in case.

Comment 8

[:kip (Kearwood Gilbert)]

I've narrowed the regression range further:

59.0a1 (2018-01-01) (64-bit) - Good
59.0a1 (2018-01-15) (64-bit) - Good
59.0a1 (2018-01-20) (64-bit) - Good
60.0a1 (2018-01-25) (64-bit) - Good
60.0a1 (2018-01-29) (64-bit) - Good
60.0a1 (2018-01-30) (64-bit) - Good
60.0a1 (2018-01-31) (64-bit) - Good
mozilla-central build built on 2018-01-31 23:56:04.850000, revision 17ade9f8 - Good
autoland build built on 2018-01-31 21:33:19.335000, revision ba88f9cd - Good

autoland build built on 2018-01-31 21:59:09.271000, revision 0936ba31 - Good

autoland build built on 2018-01-31 22:10:39.707000, revision bf1efa16 - Bad
autoland build built on 2018-01-31 23:11:15.403000, revision 982d1a88 - Bad
autoland build built on 2018-02-01 00:18:21.032000, revision 26b03e4d - Bad
mozilla-central build built on 2018-02-01 10:42:58.406000, revision 1fac52e0 - Bad
mozilla-central build built on 2018-02-01 10:54:00.893000, revision 5201997e - Bad
mozilla-central build built on 2018-02-01 18:46:03.611000, revision 946b943a - Bad
60.0a1 (2018-02-01) (64-bit) - Bad

Comment 9

[:kip (Kearwood Gilbert)]

Found the cause of the regression:

Last good revision: 0936ba31843e4aab5dd76f9310d142db311b2f41
19:09.94 INFO: First bad revision: bf1efa161edb20a83fe8db2f96c51f4e66880153
19:09.94 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0936ba31843e4aab5dd76f9310d142db311b2f41&tochange=bf1efa161edb20a83fe8db2f96c51f4e66880153

The "Force disable OSX system nano allocator" patch in Bug 1424709 has broken it.  Reversing the changes in the info.plist file allows WebVR to work again on macOS.

Comment 10

[:kip (Kearwood Gilbert)]

FWIW, I've tried updating to OpenVR 1.0.14 client source, with the same effect.

Comment 11

[Julien Cristau [:jcristau]]

Added as a known issue in 60.0 release notes.  We'll likely disable in 60.0.1 (bug 1459362).

Comment 12

[Ryan VanderMeulen [:RyanVM]]

WebVR is verified disabled on OSX for 61 now, updating the flags accordingly.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Kip, any luck? Is this still something we're aiming to enable in 62?

Comment 14

[:kip (Kearwood Gilbert)]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #13)
> Kip, any luck? Is this still something we're aiming to enable in 62?

I have found the cause of the regression and a work-around; however, the proper fix will be dependent on creating a separate process to isolate VR API access - Bug 1362578

As this will be dependent on a much bigger piece, I would plan on this slipping until 63.

@daoshengmu will be tag-teaming with me to accelerate this work.

Comment 15

[:kip (Kearwood Gilbert)]

A workaround until this is fixed:

- Stop all Firefox processes
- Use terminal to start Firefox with the MallocNanoZone environment variable set to "1":

For Firefox Release, run this:
  export MallocNanoZone=1 && /Applications/Firefox.app/Contents/MacOS/firefox

For Firefox Nightly, run this:
  export MallocNanoZone=1 && /Applications/Firefox\ Nightly.app/Contents/MacOS/firefox

- Be sure to flip "dom.vr.enabled" to "true" in about:config if using release firefox.

Do not use if you use multiple macOS "network locations" due to remote risk of crashing

Comment 16

[:kip (Kearwood Gilbert)]

Work is underway in Bug 1430038 and 1466699 to create the VR process that will enable a proper fix for this.

Comment 17

[:kip (Kearwood Gilbert)]

As patches that create entirely new processes may be too risky to uplift late in 62's beta cycle, I suggest tracking this for FF 63.

Comment 18

[:kip (Kearwood Gilbert)]

Once all the dependencies have landed, I'll upload a patch to this bug to re-enable macOS support for OpenVR.

Comment 19

[Julien Cristau [:jcristau]]

Thanks kip, moving tracking to 63.

Comment 20

[Pascal Chevrel:pascalc]

(In reply to :kip (Kearwood Gilbert) from comment #18)
> Once all the dependencies have landed, I'll upload a patch to this bug to
> re-enable macOS support for OpenVR.

Kip, can you open a separate bug for re-enabling the feature as we did for disabling it in bug 1459362 for 60.0.1? That will make tracking this for release notes easier as we already used the flag on this one for 60. Thanks!

Comment 21

[:kip (Kearwood Gilbert)]

I have created a bug and its dependencies to track the re-enabling of WebVR on macOS:

Bug 1476091 - (Re-) Enable WebVR by default for macOS

Comment 22

[Lars Bergstrom (:larsberg)]

Please track for 64.

Comment 23

[Julien Cristau [:jcristau]]

Removing tracking for 63, and ni?self to update the flags for 64 when those are available.

Comment 24

[mprogers]

So, at the end of the day, does WebVR work yet in Firefox Nightly? It does not appear to, but I have so much difficulty with SteamVR on macOS Mojave anyway that it's hard to tell where it's failing (but I do have the same problem as the original poster), using a Radeon Pro Vega 56.

Comment 25

[Daosheng Mu[:daoshengmu]]

(In reply to mprogers from comment #24)
> So, at the end of the day, does WebVR work yet in Firefox Nightly? It does
> not appear to, but I have so much difficulty with SteamVR on macOS Mojave
> anyway that it's hard to tell where it's failing (but I do have the same
> problem as the original poster), using a Radeon Pro Vega 56.

It should work properly. I just checked it in my MBP 15" with Radeon Pro 560.


1. Make sure SteamVR launches successfully, and it detects your Vive headset and controllers.
2. Open FF Nightly.
3. Go to https://webvr.info/samples/XX-vr-controllers.html, and click "Enter" button to enter the immersive mode.
4. It would work with your headset even controllers' haptic vibration.

Comment 26

[mprogers]

Thanks for the response, daoshengmu. SteamVR launches successfully, and I can play my one-and-only Mac game, SweeperVR. When I open FF Nightly, and go to that page, I see Ready, in green, and beneath that, (unresponsive Firefox) appearing in red.

Comment 27

[Daosheng Mu[:daoshengmu]]

(In reply to mprogers from comment #26)
> Thanks for the response, daoshengmu. SteamVR launches successfully, and I
> can play my one-and-only Mac game, SweeperVR. When I open FF Nightly, and go
> to that page, I see Ready, in green, and beneath that, (unresponsive
> Firefox) appearing in red.

Have you tried to click "Enter" button? It supposes you can start seeing your viewport is controlled by your headset. Sometimes, SteamVR shows red means the FPS does not fit the basic requirement of the headset (90 fps). We need to check the hardware status. Are you using an eGPU box?

The other difference is my MacOS version is 10.13.6. I am not sure if it is the reason you can't run.

Comment 28

[mprogers]

I'm not using an eGPU, rather an iMac Pro. I have no problems running under Bootcamp, so the hardware is capable. I have never had good luck with SteamVR. I'll get errors like "Hmmm, that shouldn't have happened"; or when updating the firmware, there is a link in a popup, but when I move the cursor towards it, it goes away. I understand that it's beta software, and I'd really like to help with beta testing it, but at least with my setup it's completely unusable.

Comment 29

[Daosheng Mu[:daoshengmu]]

I have verified it with (MacOS 10.14 on MBP 15" 2016) and (MacOS 10.13 on MBP 15" 2017). Both of them are running well in Nightly 65. I would like to close this bug now, please welcome to file a new if it still happens.