1543944 - Twitter - background image of video tweet is not cleared while video playing

Status: VERIFIED FIXED

(Core :: Graphics: Layers, defect)

Description

[atlanto]

Attachment: about_support.txt

STR:

1. Open https://twitter.com/nashiko_cos/status/1116634094685671424 for example

ER:
Background image turns into black when video start playing.

AR:
Background image remains while video playing.

This occurs with gfx.webrender.force-disabled=true on my pc.
With gfx.webrender.force-disabled=false by default has no problem.

mozregression:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1d58cd8e6457bae9de68d0470cf5236479ea7b2c&tochange=c2b1753a416b3201552108700ecd3d17686d5d4f

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Thanks for reporting and finding out the bug regressed this!

Though I can't reproduce the issue on Linux, I can reproduce it on Windows 10.

Comment 2

[Markus Stange [:mstange]]

The patch in bug 1538969 marks the entire bounds of the item as opaque. However, the video isn't actually displayed in the entire bounds, it is centered within the bounds depending on aspect ratio and rotation. There's code to calculate that rectangle in nsVideoFrame::BuildLayer and in CreateWebRenderCommands and it's not very straightforward - especially the handling of the rotation makes it a bit tricky.

I recommend we back out just the patch that added the GetOpaqueRegion implementation. Once Matt is back from PTO, he can take another stab at it.

Comment 3

[Markus Stange [:mstange]]

Attachment: Bug 1543944 - Don't mark nsDisplayVideo as opaque for now because we were using a rectangle that's too big. r?jya

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c992709a5b80
Don't mark nsDisplayVideo as opaque for now because we were using a rectangle that's too big. r=tnikkel

Comment 5

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/c992709a5b80

Comment 6

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello,
Reproduced the issue with Firefox 68.0a1 (20190412215855) on Windows 10 x64 using steps from comment 0.
The issue is verified using Firefox 68.0b7 (20190603181408) on Windows 10x64.