1655584 - Browser action popup sized incorrectly with X11

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Nika Layzell [:nika] (ni? for response)]

Attachment: about:support for fresh profile

Fedora 32
Nightly build 20200723212842

STR: Create a new profile, install myqonly (https://addons.mozilla.org/en-CA/firefox/addon/myqonly/), and click on the browser action.
Expected: The browser action popup is correctly sized, showing the full body.
Actual: Intermittently, the browser action popup is sized incorrectly, cutting off some of the content.

I've attached a copy of my about:support, and will include a screenshot.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

Attachment: broken_popup_fresh.png

Comment 2

[Nika Layzell [:nika] (ni? for response)]

This seems like it might be a webrender-related issue, as it appears that I have webrender enabled even on my fresh profile (based on the above about:support).

Comment 3

[Matt Woodrow (:mattwoodrow)]

Nika, can you please try disabling webrender (gfx.webrender.force-disabled=true) and see if it still reproduces?

I haven't been able to repro on any of my machines yet.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

I haven't tried for that long, but I haven't been able to reproduce this issue since disabling webrender on my primary profile. I'll update this issue if I am able to reproduce with webrender disabled within the next day or so.

The issue still occurs after a few minutes when webrender is enabled. In addition to the view with part of the pop-up missing, I also occasionally see a variant where the missing part is replaced by pixel static, suggesting it may be random video memory / a gpu issue.

Laptop is a Lenovo X1C 6th gen (if that info isn't in about:support), and I'm running Fedora 32 with Wayland disabled attached to 2 external displays through the thinkpad dock.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

Checking back in, I haven't had the issue occur at all since I turned off WebRender 6 days ago. It seems to be directly caused by WebRender.

Comment 6

[Darkspirit]

There was a regression in 80: bug 1652743

(Nika Layzell [:nika] from comment #4)

In addition to the view with part of the pop-up missing, I also occasionally see a variant where the missing part is replaced by pixel static, suggesting it may be random video memory / a gpu issue.

That's bug 1656211 / bug 1502519 (with EGL/X11: bug 1650246)

Comment 7

[Nika Layzell [:nika] (ni? for response)]

Attachment: myqonly_wr_031120.png

I still see this issue today on Fedora 33 with native WebRender enabled. I've attached an updated screenshot.

Comment 8

[Nika Layzell [:nika] (ni? for response)]

Attachment: about:support (Nov. 3, 2020)

Comment 9

[Nika Layzell [:nika] (ni? for response)]

A few additional notes:

• This fairly consistently reproduces on my local machine, so it should be straightforward for me to test a build with a potential fix.
• The empty area in the above screenshot is often filled with garbage static, as-if it's drawing uninitialized video memory. The right column which is rendering correctly in the screenshot never appears corrupted.
• I only ever really see this happen with extension pop-ups, not with native ones, so it may have something to do with the pop-up rendering remote content.
• As my about:support notes, I have fission enabled.
• The glitched area is still interactable, and shows the mouse hover cursor etc. Clicking on a link in the popup will cause the UI to render correctly for a split second before closing.

Comment 10

[Andrew Osmond [:aosmond] (he/him)]

Same as bug 1656211, but it seems I didn't fix it always based on the reports. There is an element of timing when the recomposite comes in and if it comes too early (or gets discarded), the issue remains. If I delay the composite by 5s, it seems to always clear up. Investigation continues.

Comment 11

[Andrew Osmond [:aosmond] (he/him)]

Specifically it appears that the invalidate rendered frame transaction can come in before the first draw occurs. As a result, it will never recomposite the frame as desired (until the user interacts with the popup in a way that causes it to be rerendered).

Comment 12

[Andrew Osmond [:aosmond] (he/him)]

Nika, would you be able to give this build a try to confirm whether or not this resolves the issue for you:
https://treeherder.mozilla.org/jobs?repo=try&revision=030a2a245844fa09aff939a0a6e99f5667c4b1f2

Comment 13

[Andrew Osmond [:aosmond] (he/him)]

darkspirit, see comment 12. Another pair of hands verifying this would be appreciated :).

Comment 14

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1655584 - Flush rendering for popup window configuration changes with GTK.

This backs out part of bug 1656211 which turned out to be insufficient.
The invalidate rendered frame transaction races with the initial frame
rendering of the popup. If it comes in too soon, we will only draw the
frame once, and the frame corruption remains. This patch makes us flush
the rendering pipeline to ensure we get two separate generate frame
events.

Comment 15

[Viktor Jägersküpper]

I tested the try build and unfortunately I still see this bug, for example by clicking on the library button and then hovering the mouse pointer to the "Show sidebar" button, but I also see the bug randomly when I just click on the library button.

This is on AMD Caicos with Mesa 20.2.1 using XWayland.

Comment 16

[Andrew Osmond [:aosmond] (he/him)]

(In reply to Viktor Jägersküpper from comment #15)

I tested the try build and unfortunately I still see this bug, for example by clicking on the library button and then hovering the mouse pointer to the "Show sidebar" button, but I also see the bug randomly when I just click on the library button.

This is on AMD Caicos with Mesa 20.2.1 using XWayland.

Thanks, I'll try on XWayland myself to see if the race is different. In the meantime, I've pushed a build request to try which adds extract prints for popups, which I'll needinfo you on if I can't reproduce / once it finishes:

https://treeherder.mozilla.org/jobs?repo=try&revision=c35e4fbbc14ba3202042c885eb9dcd8ac35be605

Comment 17

[Andrew Osmond [:aosmond] (he/him)]

Okay, this does still happen with xwayland for me as well, although it appears to clear itself up after a few seconds, which I did not ever see on x11 before the patch. Do you have the option to run in x11 to compare? Thanks!

Comment 18

[Viktor Jägersküpper]

I tested both try builds on X11 and couldn't reproduce the bug this way. Using XWayland the second try build makes the bug appear muss less often as it seems to me.

For the record: I am using Gnome (for both XWayland and X11) and I have a very old dual core CPU (Core 2 Duo) which might affect what I observe.

Comment 19

[Andrew Osmond [:aosmond] (he/him)]

Thanks, I will clone the bug for XWayland and consider it fixed for X11.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/da1e56ed3b88
Flush rendering for popup window configuration changes with GTK. r=sotaro

Comment 21

[Narcis Beleuzu [:NarcisB]]

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