1385586 - Content browser is not repainted if nsWindow::OnCompositedChanged is called after X compositor appears or disappears

Status: NEW

(Core :: Widget: Gtk, defect, P5)

Description

[Andreas Tolfsen ❲:ato❳]

First of all, please excuse my lack of knowledge of the widget and
painting layer.  I am probably using the wrong terminology here.

https://bugzilla.mozilla.org/show_bug.cgi?id=1364355 introduced support
for ARGB windows with OMTC when an X compositor is active.

Part of this change was hooking up the GTK signal "composited-changed"
in https://hg.mozilla.org/mozilla-central/rev/d04f932669e7.
This introduced a new composited_changed_cb callback that calls
nsWindow::OnCompositedChanged:

> void
> nsWindow::OnCompositedChanged()
> {
>   if (mWidgetListener) {
>     nsIPresShell* presShell = mWidgetListener->GetPresShell();
>     if (presShell) {
>       // Update CSD after the change in alpha visibility
>       presShell->ThemeChanged();
>     }
>   }
>   CleanLayerManagerRecursive();
> }

This function gets called when the X compositor appears or
disappears.  On my system I use the standalone compositor Compton
(https://github.com/chjj/compton) which can be started and restarted
within the window manager session.

When this happens, the Firefox content browser disappears and is replaced
with a white colour (see first screenshot).  The document is still there,
and links can still be clicked.

Selecting another tab and returning to the original tab causes its
background to turn grey with a spinner, which I assume is the e10s/remote
browser load spinner (see second screenshot).

Commenting out the "composited-changed" signal in widget/gtk/nsWindow.cpp,
or stopping the compositor from restarting, fixes this problem:

>         g_signal_connect(mShell, "composited-changed",
>                          G_CALLBACK(composited_changed_cb), nullptr);




First of all, please excuse my lack of knowledge of the widget and
painting layer.  I am probably using the wrong terminology here.

https://bugzilla.mozilla.org/show_bug.cgi?id=1364355 introduced support
for ARGB windows with OMTC when an X compositor is active.

Part of this change was hooking up the GTK signal "composited-changed"
in https://hg.mozilla.org/mozilla-central/rev/d04f932669e7.
This introduced a new composited_changed_cb callback that calls
nsWindow::OnCompositedChanged:

> void
> nsWindow::OnCompositedChanged()
> {
>   if (mWidgetListener) {
>     nsIPresShell* presShell = mWidgetListener->GetPresShell();
>     if (presShell) {
>       // Update CSD after the change in alpha visibility
>       presShell->ThemeChanged();
>     }
>   }
>   CleanLayerManagerRecursive();
> }

This function gets called when the X compositor appears or
disappears.  On my system I use the standalone compositor Compton
(https://github.com/chjj/compton) which can be started and restarted
within the window manager session.

When this happens, the rendering of the Firefox content browser disappears
and is replaced with a white colour (see first screenshot).  The document
is still there, and links can still be clicked.

Selecting another tab and returning to the original tab causes its
background to turn grey with a spinner, which I assume is the e10s/remote
browser load spinner (see second screenshot).

Commenting out the "composited-changed" signal in widget/gtk/nsWindow.cpp,
or stopping the compositor from restarting, fixes this problem:

>         g_signal_connect(mShell, "composited-changed",
>                          G_CALLBACK(composited_changed_cb), nullptr);

It is also possible to reload the document by opening two new tabs and
paste the URL of the missing tab in the second one.  The first tab that
is opened exhibits the same problem as the tab where the content browser
went away.

However, it seems like Firefox should take into account that a compositor
could be reloaded and it’s not ideal for the browser content to go
away when it does.

Comment 1

[Andreas Tolfsen ❲:ato❳]

Sorry for the double post.

Comment 2

[Andreas Tolfsen ❲:ato❳]

Attachment: screenshot-2017-07-29-180323.png

Comment 3

[Andreas Tolfsen ❲:ato❳]

Attachment: screenshot-2017-07-29-175323.png

Comment 4

[Karl Tomlinson (:karlt)]

Thank you for the analysis here.  This should be addressed by changes for bug 1377950.

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1552613