User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

On a WebVR-capable system (Oculus Rift, HTC-Vive) just doing this simple call causes constant ~13% CPU need:

if (navigator.getVRDisplays)
{
navigator.getVRDisplays().then( function(){} );
}

Here a test page:
https://krpano.com/firefox/bugs/webvr_idle_cpu_need/

Look into the task-manager after opening that page.

Tested on Windows 7 and Windows 10 using Firefox 65 with Oculus Rift and HTC-Vive.

A few more notes:

• After closing the tab of a WebVR page, it takes a few seconds until the CPU usage goes back to 0% again.

• This affects all pages that are detecting or using WebVR.

I guess it might have been resolved in Beta and Nightly at Bug 1514417. Could you take a try to see if there is still the same result in Beta?

Thanks.

Hi, no sorry, that seems to be a different problem - I've just tested Nightly 67.0a1 (2019-02-13) (64-bit) and it behaves the same as in Firefox 65.0.1 - 13% CPU need on my machine just by calling getVRDisplays and nothing else...

We have just landed a fix for Bug 1537550, which caused some overhead with IPC on every vsync that would be triggered after getVRDisplays. I am hopeful that this has made some impact on your test case.

Thanks!
Is that fix already in the currently Nightly build from today?

I've just tested Nightly 68.0a1 (2019-04-02) (64-Bit) and the bug is still there in that version... (but will test tomorrow again of course).

Tested now the next Nightly build, but the problem is still there.

Btw - it seems that this happens on EVERY system, even without a VR system installed.

I've tested this now also on an older MacMini, there the CPU usage goes up to 20% while doing nothing. Maybe interesting: the OSX Activity Monitor shows an increase of the 'Idle Wake Ups' to ~2000 while the page is open.

Just as reminder you can test and see that bug anytime here:

https://krpano.com/firefox/bugs/webvr_idle_cpu_need/

View the page-source, that's basically a one-liner, only a call to getVRDisplays.

Some major refactoring affecting this is happening in Bug 1473402. I'd suggest re-visiting after that lands.

(In reply to :kip (Kearwood Gilbert) from comment #7)

Some major refactoring affecting this is happening in Bug 1473402. I'd suggest re-visiting after that lands.

Bug 1473402 and Bug 1466702 have landed, including a re-implementation of most of VRManager and its related classes.

Could you please check if this has made an improvement?

Hi, tested now the current Nightly - version 69.0a1 (2019-07-03) (64-Bit) - but there it is still not fixed...
Should that fixes already be included there?