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

NEW
Unassigned

Status

()

Core
Widget: Gtk
9 months ago
8 months ago

People

(Reporter: ato, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 months ago
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.
(Reporter)

Comment 1

9 months ago
Sorry for the double post.
(Reporter)

Updated

9 months ago
Depends on: 1364355
(Reporter)

Comment 2

9 months ago
Created attachment 8891675 [details]
screenshot-2017-07-29-180323.png
(Reporter)

Comment 3

9 months ago
Created attachment 8891676 [details]
screenshot-2017-07-29-175323.png
(Reporter)

Updated

9 months ago
Summary: Content browser is not repainted nsWindow::OnCompositedChanged is called after X compositor appears or disappears → Content browser is not repainted if nsWindow::OnCompositedChanged is called after X compositor appears or disappears
Thank you for the analysis here.  This should be addressed by changes for bug 1377950.
No longer depends on: 1364355
You need to log in before you can comment on or make changes to this bug.