1383107 - [VR] Browser crash if the user opens a different page in a new tab

Status: RESOLVED DUPLICATE of bug 1285152

(Core :: WebVR, defect)

Description

[Ciprian Georgiu, Desktop QA]

[Affected versions]:
- 55.0b10 

[Affected platforms]:
- Windows 10

[Steps to reproduce]:
1. Launch Fx and go to https://aframe.io/a-painter/ 
2. Click from the page the VR button to start the demo
3. Open a new tab and go to a webpage (i.e. www.youtube.com)

[Expected result]:
- The experience goes smoothly.

[Actual result]:
- The browser crashes

[Regression range]:
- This is not a regression as this feature is new.

[Additional notes]:
- Crash signatures: 
https://crash-stats.mozilla.com/report/index/615b8dee-1146-4efa-8c19-9d27d0170720
https://crash-stats.mozilla.com/report/index/43f004e2-57d5-4731-aca8-7e0590170720
https://crash-stats.mozilla.com/report/index/0690f0db-3569-4a2f-907c-bd0880170720

Comment 1

[Daosheng Mu[:daoshengmu]]

I can reproduce it a few times on Oculus Rift but not always. It crashes at mContext->PSSetShaderResources(0 /* 0 == TexSlot::RGB */, 1, &srView); of VRDisplayOculus::SubmitFrame()

Comment 2

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

SoftVision has deemed this blocking for WebVR go live in 55. Lars mentioned the possibility of getting an uplift ready by Thursday am (in 55.0b13). Tracked as blocking for 55.

Comment 3

[:kip (Kearwood Gilbert)]

(In reply to Daosheng Mu[:daoshengmu] from comment #1)
> I can reproduce it a few times on Oculus Rift but not always. It crashes at
> mContext->PSSetShaderResources(0 /* 0 == TexSlot::RGB */, 1, &srView); of
> VRDisplayOculus::SubmitFrame()

At first I expected this case, but after looking at the crash reports, there are no call stacks with gfxVROculus.cpp for Firefox 55.  There were some in Firefox 56 and 54; however.  I suspect this is due to the previous bug which affected 54 and the recent regression with the advanced layers affecting 56.

Comment 4

[:kip (Kearwood Gilbert)]

I notice in the crash correlation reports for this crash signature, that there are a high correlation of Tab related add-ons:

(19.23% in signature vs 00.10% overall) Addon "Close Tab by Double Click" = true
(23.08% in signature vs 00.23% overall) Addon "Duplicate Tabs Closer" = true
(23.08% in signature vs 00.05% overall) Addon "Tab Kit - Mouse Gestures" = true
(26.92% in signature vs 00.66% overall) Addon "Tree Style Tab" = true
(19.23% in signature vs 00.06% overall) Addon "Open Selected Links" = true
(23.08% in signature vs 00.05% overall) Addon "Rights To Close" = true
(23.08% in signature vs 00.05% overall) Addon "Tab Kit - Mouse Gestures" = true

Where any such add-ons installed when the problem was reproduced?

Comment 5

[:kip (Kearwood Gilbert)]

(In reply to :kip (Kearwood Gilbert) from comment #4)
> I notice in the crash correlation reports for this crash signature, that
> there are a high correlation of Tab related add-ons:
> 
> (19.23% in signature vs 00.10% overall) Addon "Close Tab by Double Click" =
> true
> (23.08% in signature vs 00.23% overall) Addon "Duplicate Tabs Closer" = true
> (23.08% in signature vs 00.05% overall) Addon "Tab Kit - Mouse Gestures" =
> true
> (26.92% in signature vs 00.66% overall) Addon "Tree Style Tab" = true
> (19.23% in signature vs 00.06% overall) Addon "Open Selected Links" = true
> (23.08% in signature vs 00.05% overall) Addon "Rights To Close" = true
> (23.08% in signature vs 00.05% overall) Addon "Tab Kit - Mouse Gestures" =
> true
> 
> Where any such add-ons installed when the problem was reproduced?

Sorry, I see from the crash report telemetry that such addons were not present in these cases.

Comment 6

[:kip (Kearwood Gilbert)]

(In reply to :kip (Kearwood Gilbert) from comment #3)
> (In reply to Daosheng Mu[:daoshengmu] from comment #1)
> > I can reproduce it a few times on Oculus Rift but not always. It crashes at
> > mContext->PSSetShaderResources(0 /* 0 == TexSlot::RGB */, 1, &srView); of
> > VRDisplayOculus::SubmitFrame()
> 
> At first I expected this case, but after looking at the crash reports, there
> are no call stacks with gfxVROculus.cpp for Firefox 55.  There were some in
> Firefox 56 and 54; however.  I suspect this is due to the previous bug which
> affected 54 and the recent regression with the advanced layers affecting 56.

Correction:

1 / 3 of the crash reports included the line reported by @daoshengmu.

I'll continue investigating.

Comment 7

[Diego Marcos [:dmarcos]]

I was not able to reproduce this on neither HTC Vive or Oculus Rift with Firefox 55.0b12

Comment 8

[:kip (Kearwood Gilbert)]

Perhaps this is another permutation of device context loss:


Bug 1285152 - Crash in CContext::TID3D11DeviceContext_SetShaderResources_<T>

This crash is happening outside of WebVR as well, with various call stacks leading to SetShaderResources.


I'll try to artificially induce this crash...

Comment 9

[:kip (Kearwood Gilbert)]

All three of the crash reports appear to be a result of device reset events.

The telemetry logged the events, with message such as:

|[0][GFX1-]: Failed to do glGetActiveAttrib: 1282 (t=103.405) |[181][GFX1-]: (gfxWindowsPlatform) Detected device reset: 2 (t=273.453) |[182][GFX1-]: (gfxWindowsPlatform) Finished device reset. (t=273.453) |[183][GFX1-]: LayerManager::EndTransaction skip RenderLayer(). (t=273.508) |[184][GFX1-]: (nsWindow) Detected device reset: 7 (t=273.508) |[185][GFX1-]: (nsWindow) Finished device reset. (t=273.614) |[171][GFX1-]: GFX: D3D11 skip BeginFrame with device-removed. (t=271.949) |[172][GFX1-]: (nsWindow) Finished device reset. (t=272.111) |[173][GFX1-]: D3D11 swap chain preset failed 0x887a0005 (t=272.378) |[174][GFX1-]: [CompositorD3D11] device removed with error code: 0x887a0005, 0x887a0005, 0 (t=272.378) |[175][GFX1-]: (gfxWindowsPlatform) Detected device reset: 7 (t=272.488) |[176][GFX1-]: (gfxWindowsPlatform) Finished device reset. (t=272.488) |[177][GFX1-]: (nsWindow) Detected device reset: 7 (t=272.488) |[178][GFX1-]: (nsWindow) Finished device reset. (t=272.65) |[179][GFX1-]: D3D11 swap chain preset failed 0x887a0005 (t=273.453) |[180][GFX1-]: [CompositorD3D11] device removed with error code: 0x887a0005, 0x887a0005, 0 (t=273.453) 

This appears to be a duplicate of Bug 1285152 and not VR specific.  When the solution to Bug 1285152 is determined, the solution may require changes to WebVR code or be done more universally.  Fixing this for WebVR only would fix 1/3rd of these cases.

I'll do a bit more digging as a sanity check to ensure I haven't missed anything.

Comment 10

[:kip (Kearwood Gilbert)]

The telemetry shows that the NVidia driver in use was 22.21.13.8205 (382.05) which was released on 2017.5.4

There are known problems with VR with that driver version.

Could you please use the latest NVidia driver (384.94, released on 2017.7.24) and advise if the problem still persists?

Comment 11

[:kip (Kearwood Gilbert)]

I'll file this as a duplicate of Bug 1285152.

Please re-open or file a new bug if this can be repro-ed on a more recent driver (that doesn't have known hot-fixes or known VR incompatibilities)

It is not likely that end users with VR hardware will be using this particular driver version, as it is known to cause problems with VR outside of Firefox.

Comment 12

[Daosheng Mu[:daoshengmu]]

After update to 55.0b12 (64-bit), I can't reproduce it on Oculus Rift either. btw, my NVidia driver in use is 378.92.

Comment 13

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

(In reply to :kip (Kearwood Gilbert) from comment #10)
> The telemetry shows that the NVidia driver in use was 22.21.13.8205 (382.05)
> which was released on 2017.5.4
> 
> There are known problems with VR with that driver version.
> 
> Could you please use the latest NVidia driver (384.94, released on
> 2017.7.24) and advise if the problem still persists?

I re-tested this issue using Fx 55.0b13 and updated the drivers (the ones released on 2017.7.24).
HTC Vive has no issue.
Oculus does not crash any longer, however there are some user experience impacting glitches.

Comment 14

[Julien Cristau [:jcristau] (back April 22)]

Unsetting tracking flags since this was resolved as a duplicate and isn't a blocker.