1742358 - [Linux] Firefox window is transparent / flashing right after browser start

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Martin Stránský [:stransky] (ni? me)]

Before we paint UI/web content the Firefox window is empty and transparent so you see desktop background. Firefox on Windows use a placeholder screen which is replaced by actual Firefox content when we're loaded.

I wonder if we can use such placeholder on Linux too.

Comment 1

[Martin Stránský [:stransky] (ni? me)]

The placeholder on Window look like a normal Firefox window but has empty area for web content and bold gray line instead of URL.

Comment 2

[:Gijs (he/him)]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #0)

Before we paint UI/web content the Firefox window is empty and transparent so you see desktop background. Firefox on Windows use a placeholder screen which is replaced by actual Firefox content when we're loaded.

We used to at least paint a blank window (using about:blank). Do you know why that is not working, ie why is it transparent rather than white/black? Is that a regression? Does it happen with/without webrender and/or wayland?

I wonder if we can use such placeholder on Linux too.

This part feels like a separate enhancement. It should be a smaller lift to fix the transparency, at least.

Comment 3

[:Gijs (he/him)]

Looks like the blank window bit should work on nightly, per bug 1450626 and https://searchfox.org/mozilla-central/rev/70b32246fce5ca1f53af573a21c1939df58cb969/browser/app/profile/firefox.js#309 .

Comment 4

[Martin Stránský [:stransky] (ni? me)]

We can postpone window show at widget level or set the transparency later and show just blank window. The problem is that widget code does not know when the window has a valid content - can this be obtained somehow?

Comment 5

[:Gijs (he/him)]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #4)

We can postpone window show at widget level or set the transparency later and show just blank window. The problem is that widget code does not know when the window has a valid content - can this be obtained somehow?

I'm not sure what you mean by "valid content" in this context, or why we're showing a window before we've loaded DOM content for it that we can present (assuming that's what "valid content" means?). Even if we do though, I would have thought we could at least paint the default window background colour, which comes from the gtk theming prefs anyway, right? But I'm guessing :dthayer and/or :emilio can give you better answers here.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Yes, I think default background would be sufficient here. It's visible in debug build - we show Firefox window (which is transparent by default) but it takes another 2-3 seconds until some content is painted.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

hm, it may be handled on widget level - we know that the window is painted to on compositor widget level.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1742358 - Set default clear color to widget window background on expose, and reset it on first contentful paint. r=jrmuizel!,stransky!

Something like this mostly works, except for the fact that it breaks
rounded corners because we still clear with the opaque color behind
them.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Sorry for the lag. The patch above seems to work except for the issue hinted in the comment. We might be able to set the clear color to transparent after we've painted the chrome document. The issue is what's the best way to detect it.

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Martin pointed that perhaps a better way is delaying the call to https://searchfox.org/mozilla-central/rev/253ae246f642fe9619597f44de3b087f94e45a2d/widget/gtk/nsWindow.cpp#5689

Comment 11

[Emilio Cobos Álvarez [:emilio]]

removing that call or making that call pass false worked on wayland but not x11 (and still didn't show the rounded corners properly), so I went ahead with my initial solution, it wasn't a lot of work.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7e3cdb88790d
Set default clear color to widget window background on expose, and reset it on first contentful paint. r=jrmuizel,stransky

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c4d886e0717a
Use non-blank paint rather than contentful paint to fix test_drawWindow_widget_layers.html, which relies on transparent clear.

Comment 14

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/7e3cdb88790d
https://hg.mozilla.org/mozilla-central/rev/c4d886e0717a

Comment 15

[:Gijs (he/him)]

Did we do any talos checks on this? I'm guessing this is going to move paint / window opening numbers, though I have no idea in which direction...

Comment 16

[Emilio Cobos Álvarez [:emilio]]

I didn't, but I don't know why it would have any measurable effect on performance?

It doesn't really change how much paint work is done, just with which color does WR do the clear (so at most two more IPC messages with just one uint32_t each).

Comment 17

[Emilio Cobos Álvarez [:emilio]]

I mean, conceptually the OS compositor could optimize something with the opaque clear color, so it could be faster, but it's hard to imagine how would it get that information without us telling it.

Comment 18

[:Gijs (he/him)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #16)

I didn't, but I don't know why it would have any measurable effect on performance?

Ah, sorry, I think I got confused wrt the idea of postponing one of the calls (comment #4 / comment #10), but I guess that's not the fix we went with.

Comment 19

[Robert Mader [:rmader]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)

I mean, conceptually the OS compositor could optimize something with the opaque clear color, so it could be faster, but it's hard to imagine how would it get that information without us telling it.

Just for the record:
Current hardware architectures don't allow fast checks on color opaqueness which is why on both Wayland and X11/EWMH there exists the concept of opaque-regions - a compositor hint that the area/region can be optimized. We did already set that hint before this patch, leading to small glitches if the background behind Firefox changed while the window still appeared transparent (I saw that a lot when launching a fresh debug build from terminal, as the terminal prints lots of stuff). So no, no performance differences expected from the compositor side (but the patch fixes an actual bug from the compositors point of view).

Comment 20

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The bug was closed 3 years old and doesn't seem to require any action, so clearing needinfo.