1785146 - XFCE/Nvidia: Picture in picture mode resizing a video while holding control

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Mark1100]

Attachment: 2022-08-16 22-39-09.mkv

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

1. Enable Picture in Picture mode
2. Hold the Ctrl key and try resizing the video fast like in the video I attached.

Actual results:

If I hold the control key, then try to resize the PiP video sometimes the window get buggy as you can see in the video that I attached.

Comment 1

[Molly Howell (she/her) (no longer active)]

Hi, thanks for filing this, and for recording the video, those are super helpful.

Just to be sure I understand properly, is the problem you're trying to point out the way that the window starts kind of getting copied all over the screen toward the end of the video? If so, I don't think that's actually a picture-in-picture problem, I think the window behind the PIP window isn't repainting when it should and that's what's creating this effect (although why that's happening, I'm not certain).

Comment 2

[Mark1100]

Yes that’s exactly the problem, the window getting copied.

Comment 3

[Mark1100]

Update:

I tried this in Windows right now and the problem doesn’t occur there.
So this is a Linux specific problem and it also occurs without holding the control key.

This is very interesting, because it only occurs, when I resize the PiP window very fast.
If I resize the window slowly the bug doesn’t occur.

Comment 4

[Molly Howell (she/her) (no longer active)]

Thanks for the info. I'm moving this to a place where hopefully someone knows how to help look into it further, because I'm afraid I'm a little out of my depth.

Comment 5

[Bob Hood [:bhood]]

Mark, could you please attach your about:support output to this report when you get a chance? Thanks!

Comment 6

[Bob Hood [:bhood]]

Glenn, sounds like WR. Could you confirm, please?

Comment 7

[Glenn Watson [:gw]]

It's a little hard to say - it sort of looks WR related, but WR doesn't know anything about the current PiP implementation.

I wonder if what's happening in this case is that partial present is active on Linux, but Gecko isn't asking WR to composite the main window behind when the PiP element is being moved, or something like that?

Sotaro, Mike, does that sound plausible? Or any other ideas on possible causes?

Comment 8

[Glenn Watson [:gw]]

Not knowing much about the current PiP implementation - is it a top-level (OS) window with a separate WR instance and display list?

Comment 9

[Mark1100]

(In reply to Bob Hood from comment #5)

Mark, could you please attach your about:support output to this report when you get a chance? Thanks!

https://pastebin.com/fzkUqUL6

Comment 10

[Darkspirit]

Does the same bug occur with Gnome and KDE?

Comment 11

[Mark1100]

(In reply to Darkspirit from comment #10)

Does the same bug occur with Gnome and KDE?

It only occurs in XFCE, in KDE or Gnome it works fine.
However, I only tried in live session, where there is no Nvidia driver.

I tried to run Firefox in the terminal and it says:
[GFX1-]: GFX: RenderThread detected a device reset in PostUpdate
[GFX1-]: Failed to make render context current during destroying.

Comment 12

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 13

[Sotaro Ikeda [:sotaro]]

(In reply to Glenn Watson [:gw] from comment #8)

Not knowing much about the current PiP implementation - is it a top-level (OS) window with a separate WR instance and display list?

Different window has different WR instance and display list, though GL context could be same when RenderCompositorEGL is used.
It seems like GPU and platform specific problem. I failed to reproduce the problem on ubuntu 22.04.

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Sorry for the delay!

(In reply to Glenn Watson [:gw] from comment #7)

Sotaro, Mike, does that sound plausible? Or any other ideas on possible causes?

The way PiP works is by using a completely different top-level window that asks the OS to apply a rule for keeping that window on top of others. I'm pretty sure that WR treats it like any other browser window, and (as you say) doesn't do anything particularly special for it.

I'd be interested if the streaky "you just won Windows solitaire" effect applies to other application windows as well, and not just other Firefox windows. If so, I think that'd support this being more of a GPU or OS-layer issue.