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.
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.
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?
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.
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!
Nice find, that version works for me as well.
Thanks for narrowing the regression range. I'm investigating this now, and hope to have a fix soon.
Assignee: nobody → kgilbert
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.
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
Status: NEW → ASSIGNED
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.
FWIW, I've tried updating to OpenVR 1.0.14 client source, with the same effect.
Added as a known issue in 60.0 release notes. We'll likely disable in 60.0.1 (bug 1459362).
WebVR is verified disabled on OSX for 61 now, updating the flags accordingly.
Kip, any luck? Is this still something we're aiming to enable in 62?
(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.
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
Work is underway in Bug 1430038 and 1466699 to create the VR process that will enable a proper fix for this.
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.
Once all the dependencies have landed, I'll upload a patch to this bug to re-enable macOS support for OpenVR.
Thanks kip, moving tracking to 63.
(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!
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
Please track for 64.
Removing tracking for 63, and ni?self to update the flags for 64 when those are available.
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.
(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.
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.
(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.
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.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.