Affected versions

• Latest Nightly 80.0a1

Unaffected versions

• Firefox 79.0 RC

Affected platforms

• Windows 10 64bit
• Windows 7 64bit

Steps to reproduce

1. Start Nightly
2. Visit https://hello.freeconference.com/conf/call/3243397 (demo conference room)
3. Enter a name (any string will do)
4. Click the Draw icon
5. Draw something
6. Resize Nightly from any corner

Expected result

• No flickering can be seen after following step 5 or 6.

Actual result

• Draw area flickers when drawing or by resizing Nightly (step 5 or 6).

Regression range

• First bad: 2020-04-15
• Last good: 2020-04-14
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=df4d3efbfa453cf1e0da54a44df349e130731f74&tochange=a22ce6ad4e273a47c9f4481e2462efa35b17d8eb
• Potential regressor: Bug 1547286: Enable remote Canvas 2D in Windows Nightly builds. r=jrmuizel

Additional notes

• Gif showing the issue is attached.
• I would assume this is can be marked as an S3 bug since only nightly is affected by the issue in question.

Thanks Bogdan.

I get loads of "GP+[GFX1-]: RenderDXGITextureHostOGL Failed to open shared texture, hr=0x80070057" messages while this is happening.
So that gives me something to look at.

If I disable webrender, it still flickers, but with a white background and no message.

I've found the problem here.
This manages to trigger a situation where all the references to the texture are dropped and it gets destroyed before the handle it is opened for compositing.
The type of handle we use at the moment doesn't keep the texture alive.
We could possibly use an NT handle, but there is a question mark over support on Windows 7.
We could hold a separate reference until the texture is reopened on the other device.
Possibly the easiest thing will be to ensure the texture is opened as soon as we get the descriptor for the TextureHost.

The severity field is not set for this bug.
:ktaeleman, could you have a look please?

For more information, please visit auto_nag documentation.

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.

This is a canvas 2D issue, so I don't think it's a duplicate of 1653404.
It probably is a duplicate of 1656774, but I'll have the fix up soon, so we can then confirm through testing.

This creates a unique (per content process) ID for each TextureRecorded. This is
then used as a lookup in the GPU process for the real texture.
Previously the pointer for the TextureRecorded's DrawTarget was used, but as the
translated texture is used in multiple threads in the GPU process, pointer reuse
could mean that the handle for an old texture could be picked up by mistake.

This ensures that the translated Texture in the GPU process keeps the GPU
resource alive during the period before the resource is opened by webrender.

Depends on D93501

Depends on D93502

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6bde2a25d6b63e5584b9761704452472156e6e4e

Depends on D93503

Depends on D93673

https://hg.mozilla.org/mozilla-central/rev/f1c18620c561
https://hg.mozilla.org/mozilla-central/rev/370b395bc996
https://hg.mozilla.org/mozilla-central/rev/7bcb1137e1d5
https://hg.mozilla.org/mozilla-central/rev/6db3be291797
https://hg.mozilla.org/mozilla-central/rev/49a50cf01c73