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

Steps to reproduce:

Go to https://apps.facebook.com/playmyvegas/

Actual results:

Black screen within the app after Firefox has been running a while - the app runs if Firefox is only recently opened.
GFX Failure log shows: GP+[GFX1-]: RenderDXGITextureHost Failed to open shared texture, hr=0x80070057

Expected results:

App runs.

There are other instances of the black screen on other web pages but haven't tracked those consistently.
GFX1 is AMD Radeon(TM) Graphics

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

A few questions -

1. have you experienced any crashes?
2. could you check about:crashes and see if there's anything recent?
3. Could you post your about:support text?

This sounds like a low memory problem, or a driver issue.

The problem seems to be related to oop WebGL. I am going to look into more.

Created a rough diagram of WebGL architecture on Windows.
https://github.com/sotaroikeda/firefox-diagrams/blob/master/dom/dom_canvas_WebGL_91.pdf

The following is a diagram of canvas 2d.
https://github.com/sotaroikeda/firefox-diagrams/blob/master/dom/dom_canvas_CanvasRenderingContext2D_91.pdf

The problem seemed to happen when ID3D11Texture2D is closed before it is opened by RenderDXGITextureHost. It seems similar to Bug 1654477. To prevent the problem, we needs to keep the ID3D11Texture2D alive until it is opened by RenderDXGITextureHost.

But just adding TextureFlags::WAIT_HOST_USAGE_END flag to TextureClient could not address the problem. SharedSurfaceTextureData just owns SurfaceDescriptorD3D10. It does not own the ID3D11Texture2D.

(In reply to Jim Mathies [:jimm] from comment #4)

A few questions -

1. have you experienced any crashes?
2. could you check about:crashes and see if there's anything recent?
3. Could you post your about:support text?

This sounds like a low memory problem, or a driver issue.

Sorry I can't post the entire about:support.
It's not AMD specific. The same problem with Intel UHD Graphics on two separate machines.

Same thing sometimes with Google maps - map portion on the right side as attached.

https://www.google.com/maps/place/Yanjiao,+Sanhe,+Langfang,+Hebei,+China/@39.9085764,116.6218485,10z/data=!4m5!3m4!1s0x35f19ffd8745848f:0x6702682b49c864ac!8m2!3d39.945997!4d116.809217

Am I the only one experiencing this? This bug was on a number of system with different processor/GFX cards.

This appears to have to do with dual graphics card and hdmi display.

Steps:

1. firefox.exe on integrated GPU -> laptop display
2. Switch to HDMI display <- discrete card (firefox.exe still on integrated GPU engine)
3. black box appears on certain firefox displays
4. works fine on chrome

Seems like a case of us probably trying to mix two different devices, each attached to a different GPU?

I don't know how the Windows parts work, I'd put my trust in Sotaro.

I think this is generally the buggy cross-process surface lifetime issue.

With the patch, the following STR caused the "Failed to open shared texture, hr=0x80070057".

-[1] Open https://developer.mozilla.org/ja/docs/Web/API/WebGL_API/Tutorial/Animating_objects_with_WebGL. And scroll until showing WebGL animation.
-[2] Open a new window
-[3] Open https://www.google.co.jp/maps/ in the new window.
-[4] Scale/Move in https://www.google.co.jp/maps/

As in Comment 7, the problem seems like the following.

• SharedSurface_ANGLEShareHandle was destroyed before shared handle of ID3D11Texture2D is opened by RenderDXGITextureHost::EnsureD3D11Texture2D().
• Destruction of SharedSurface_ANGLEShareHandle also caused close of the ID3D11Texture2D.

Ok, yeah, sounds like our known frame lifetime liveness problem.
We really do need a solution for this, but it's complicated since WebGLParent and wr-parent are different actors, even if they're (always?) in the same process these days.
I think it's ultimately a game of telephone where in order to be correct and sound, we have to go:

WebGLChild::HoldFrameUntilAck();
WebGLChild::SendFrameP1 -> webglparent -> compositor-child::SendFrameP2 -> compositor-parent::RecvFrameP2
                                                                                                |
                                                                                                V
WebGLChild::RecvFrameAckP2 <- webgl-parent::SendFrameAck2 <- compositor-child <- compositor-parent::SendFrameAck1
 |
 V
WebGLChild::AckReleasesFrame()

It seems that the lifetime problem could be simpler if IPC actor is used.

It seemed that almost all test failures seemed to be addressed.
https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=Xsnl_2rhQfuFAuRqw06VGw.0&revision=1e1a824fcc0bce58b28c605e4dcf4b76ebf7fa8a

glterrain became a lot better.
https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=2edf872f01af9a36832ec4d685b7be9796785fc5&newProject=try&newRevision=9938a1199cb1b9b94748e52d6969ebd7155fa839&framework=1&page=1&showOnlyConfident=1

Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.

Somehow D148888 link became invalid. Then posted as a new patch.
https://phabricator.services.mozilla.com/D150197

Kelsey prefers more simplified way. But going to land the patch for testing by disabling it.

(In reply to Sotaro Ikeda [:sotaro] from comment #27)

Kelsey prefer more simplified way. But going to land the patch for testing by disabling it.

It was my misunderstanding.

1. be fixed so it follows the spec with regard to showing exactly the right buffer, and 2) Very eventually, we should have a better way to do things
   but we don't have time to do #2 right now and it sounds like #1 isn't that hard so we should just fix it up to work with your current approach.

(In reply to Sotaro Ikeda [:sotaro] from comment #28)

(In reply to Sotaro Ikeda [:sotaro] from comment #27)

Kelsey prefer more simplified way. But going to land the patch for testing by disabling it.

It was my misunderstanding.

1. be fixed so it follows the spec with regard to showing exactly the right buffer, and 2) Very eventually, we should have a better way to do things
   but we don't have time to do #2 right now and it sounds like #1 isn't that hard so we should just fix it up to work with your current approach.

I agree because this bug is really severe.

Backed out for causing build bustages on LayersSurface

Backout link

Push with failures

Failure log 1 // Failure log 2

Addressed build failure.
https://treeherder.mozilla.org/jobs?repo=try&revision=9f6c50733deea15755dc66dabeccb353e4148930

https://hg.mozilla.org/mozilla-central/rev/69064ec2225e

Hello! Perfherder has detected this alert https://treeherder.mozilla.org/perfherder/alerts?id=34690
After investigating it looks like the cause could be 69064ec2225eef5f5900a58698e782a411368162. The graph is pretty noisy and unstable. What do you think? Is it alright to file a bug for this?

Hmm, the change seems not related to the alert. It seems not cause such size change.

I'm on Firefox 104 now, and the black screen is still showing when I'm on a different graphics card.

Bug 1776148 is going to fix the problem, but depending bug of Bug 1776885 became larger than I expected.

(In reply to Sotaro Ikeda [:sotaro] from comment #38)

Bug 1776148 is going to fix the problem, but depending bug of Bug 1776885 became larger than I expected.

Not sure to understand, is the bug fixed ? Cause I still got the bug on firefox 105.0.1.

If Bug 1791693 is addressed the problem should also be addressed. Bug 1776148 was replaced by Bug 1791693.
Can you check if pref webgl.out-of-process.async-present = true works on nightly? pref could be changed from about:config.