1565268 - Immersive mode doesn't exit correctly when exiting after JS execution is paused

Status: VERIFIED FIXED

(Core :: WebVR, defect, P2)

Description

[Manuel Martin]

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

Steps to reproduce:

Test with FxR using immersive_dialog branch https://github.com/MozillaReality/FirefoxReality/tree/immersive_dialog

• Open https://codepen.io/keianhzo/project/full/XvgYNr
• Enter Immersive mode
• Click on the controller trigger

Actual results:

Immersive mode exits and after the alert is dismissed, the WebVR app is still in immersive mode.
If instead of exiting immersive triggering a prompt, the controller back button is used, immersive mode exits correctly.

It seems that this could happen if immersive is exited after any JS call that triggers a JS execution pause, like alerts or any other prompts.

Expected results:

Immersive mode should be exited correclty same as when using the back button.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:kip, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Daosheng Mu[:daoshengmu]]

will it fix by Bug 1587366? If no, I am going to jump in.

Comment 3

[Imanol Fernandez]

(In reply to Daosheng Mu[:daoshengmu] from comment #2)

will it fix by Bug 1587366? If no, I am going to jump in.

Bug 1587366 doesn't fix this one.

Comment 4

[Daosheng Mu[:daoshengmu]]

It happens in WebVR desktop either, but in Windows, it is caused by VRService[1] is forced to shutdown because the service doesn't update for a while.

For Android, it is a different story. Android doesn't use VRService. the VRManager will shutdown [2] finally, we can consider to use this new displayInfo to leave the current immersive mode by ExternalVR::StopPresenting in FxR.

[1] https://searchfox.org/mozilla-central/rev/17756e2a5c180d980a4b08d99f8cc0c97290ae8d/gfx/vr/service/VRService.cpp#259
[2] https://searchfox.org/mozilla-central/rev/17756e2a5c180d980a4b08d99f8cc0c97290ae8d/gfx/vr/VRManager.cpp#859.

Comment 5

[Daosheng Mu[:daoshengmu]]

I think the right fixing place needs to be in Gecko. When VRService is shutdown, we need to figure out how to fire a vm->FireDOMVRDisplayPresentChangeEvent(mDisplayInfo.mDisplayID); event in VRDisplayClient

Comment 6

[Daosheng Mu[:daoshengmu]]

When the VRService is shutdown, we will create a new VRDisplayClient at [1]. Then, posting vrdisplayconnect event to Globalwindow [2] with the new VRdisplay [3], the previous VRDisplay is removed from VRManagerChild, and it seems like can't receive events more.

However, in JS side, it is still using the previous VRDisplay and its VRDisplayClient. So, we can't submit frames after requesting presenting [4] because its frameId will no longer be updated from new VRDisplayInfo [5].

[1] https://dxr.mozilla.org/mozilla-central/rev/273c3db836e1a2ffdb7ce46d28d85adbbf2b70ba/gfx/vr/ipc/VRManagerChild.cpp#198
[2] https://dxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindowInner.cpp#6377
[3] https://dxr.mozilla.org/mozilla-central/rev/273c3db836e1a2ffdb7ce46d28d85adbbf2b70ba/dom/vr/VRDisplay.cpp#98
[4] https://dxr.mozilla.org/mozilla-central/source/gfx/vr/ipc/VRLayerChild.cpp#48
[5] https://dxr.mozilla.org/mozilla-central/rev/273c3db836e1a2ffdb7ce46d28d85adbbf2b70ba/gfx/vr/VRManager.cpp#496

Comment 7

[Daosheng Mu[:daoshengmu]]

Attachment: Bug 1565268 - Recovering VRDisplay status after VRService is shutdown.

When JS is paused, VRService will automatically shutdown because the timer is not updated, we used to create a new VRDisplay to JS. However, the page is still using the older VRDisplay, so it can't get the newest VRDisplayInfo status. We should exit presentation and apply the VRDisplayInfo status to the original VRDisplay instead of creating new one.

Comment 8

[Daosheng Mu[:daoshengmu]]

It doesn't work for FxR though. The VRManager::SubmitFrame() stops to be called after a few frames. I am investigating.

Comment 9

[Daosheng Mu[:daoshengmu]]

(In reply to Daosheng Mu[:daoshengmu] from comment #8)

It doesn't work for FxR though. The VRManager::SubmitFrame() stops to be called after a few frames. I am investigating.

I have confirmed the reason that breaks Android is org.mozilla.vrbrowser E/libEGL: eglMakeCurrent:796 error 300d (EGL_BAD_SURFACE) that makes VRManagerChild::RecvUpdateDisplayInfo can't receive new events from the parent side. That looks like the java::GeckoSurfaceTexture is broken when trying to go back to the immersive mode. So, I think I have to release the VRScreen screenbuffer first.

Comment 10

[Daosheng Mu[:daoshengmu]]

Attachment: Bug 1565268 - Recovering VRDisplay status after VRService is shutdown.

When JS is paused, VRService will automatically shutdown because the timer is not updated,
we used to create a new VRDisplay to JS. However, the page is still using the older VRDisplay,
so it can't get the newest VRDisplayInfo status. We should exit presentation and
apply the VRDisplayInfo status to the original VRDisplay instead of creating new one.

Besides, we also need to release the VR screen buffer after exiting the immersive mode to avoid eglMakeCurrent error.

Comment 11

[Daosheng Mu[:daoshengmu]]

Try looks good, https://treeherder.mozilla.org/#/jobs?repo=try&revision=b4de4233c8fbfa608a49d424f5ce7614935bffdb

Comment 12

[Daosheng Mu[:daoshengmu]]

Attachment: Bug 1565268 - Part 2: Removing mDisplayName/Id from VRDisplay.

We can remove mDisplayName/Id and just use VRDisplayInfo to get these two values.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4d18e8024acf
Recovering VRDisplay status after VRService is shutdown. r=kip,jgilbert
https://hg.mozilla.org/integration/autoland/rev/b70aa06f74d5
Part 2: Removing mDisplayName/Id from VRDisplay. r=kip

Comment 14

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/4d18e8024acf
https://hg.mozilla.org/mozilla-central/rev/b70aa06f74d5

Comment 15

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I can confirm this issue is fixed, I verified using Fx 72.0, 73.0b1 and 74.0a1, using Oculus Rift.