1210249 - set GTK_CSD=1 doesn't redraw background apps when moving Firefox window

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Karl Tomlinson (:karlt)]

Reported in bug 1195002 comment 55:

While the window decoration issues are solved, there is now an area around a non-maximized window, that doesn't get cleared. You can see remnants of the full screen window of Firefox and resizes in the screenshot. I've also moved the window, that's why the "background" from the text editor is offset. This is from the ubuntu PPA firefox-trunk nightly built on the 29th September.

(In reply to Martin Stránský from bug 1195002 comment #56)
> Martin, which system do you run, how can I reproduce that? It is the Feya OS
> or some Ubuntu version?

elementary OS 0.3 Freya with GTK 3.14.15. By the way, I noticed that when dragging a window from being maximized to windowed, the cursor stays on top of the not-redrawn window, while the decorations (as visible in the screenshot) are farther down, but that could very well be an issue with elementary OS, because I recall similar oddities with other programs (namely, the window maximizing before you touch the top of the screen).

Comment 1

[Karl Tomlinson (:karlt)]

Are you able to report, please, whether other GTK3 applications, or the file open dialog, reproduce the problem with the redrawing background apps?

Redrawing the background apps is the responsibility of the window manager (when it is compositing, as here).  It hard to imagine how the app could control this.

Comment 2

[leetnux]

Other GTK3 applications and the file open dialog not cause the issue.

Comment 3

[Martin Giger [:freaktechnik]]

(In reply to Karl Tomlinson (ni?:karlt) from comment #1)
> Are you able to report, please, whether other GTK3 applications, or the file
> open dialog, reproduce the problem with the redrawing background apps?
This happens just with windows from Gecko applications. Plus it's not background apps, but just an area around the window itself - which I suspect is used for drawing the shadow around the window. I just noticed that it depends on resizing the window. A newly opened window/dialog is fine (except that its size is off, but that's bug 1209659), until you resize it. The background of the area only stops being transparent in the regions affected by the resize (I initially had the impression it was always alla round the window, because I had the window maximized on start), however the shadow is still drawn over the existing one around the whole window (easily noticeable, since it gets darker).

You can clearly see the area which isn't transparent anymore and that the shadows are layered in the screenshot attached to bug 1195002 comment 55. If you want a reference to how the window shadow should look, see the screenshots in bug 1209659.

And no, the gtk file picker does not have that issue.

> Redrawing the background apps is the responsibility of the window manager
> (when it is compositing, as here).  It hard to imagine how the app could
> control this.
Yes, other apps get redrawn correctly, it seems that somehow the area around the window just loses its transparency and shadows aren't cleared and get drawn over.

Comment 4

[Karl Tomlinson (:karlt)]

(In reply to Martin Giger [:freaktechnik] from comment #3)
> > Redrawing the background apps is the responsibility of the window manager
> > (when it is compositing, as here).  It hard to imagine how the app could
> > control this.
> Yes, other apps get redrawn correctly, it seems that somehow the area around
> the window just loses its transparency and shadows aren't cleared and get
> drawn over.

Ah, OK, thanks.  That is GTK drawing those, and how the window manager composites may depend on _NET_WM_OPAQUE_REGION.

xprop can xwininfo can be used to see whether _NET_WM_OPAQUE_REGION is sane.

Gecko is probably unique in having a child window, but maybe Gecko has the wrong dimensions on that child window.  xwininfo can test that.

Comment 5

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

Yes, I can see that on Freya OS.

Comment 6

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

> xprop can xwininfo can be used to see whether _NET_WM_OPAQUE_REGION is sane.

The extends seems to be okay - compared with other gtk3 app with the same size (tested on midory).

Comment 7

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

BTW. setting GTK_CSD=1 makes such frames on Fedora too. So seems to a general issue.

Comment 8

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

That seems to be a bug in our resize code. The window is rendered correctly (also moves correctly) until it's resized. Then it gets the broken background. The resize code also produces the pixman error messages, caused by negative allocation size (height is negative).

Comment 9

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

This bug is caused by disabled double buffering on the mShell (outer) widget when mContainer has the rendering window and CSD is enabled. Karl, do we actually need to listen on visibility events for the mShell in that case? I think we don't need that.

Comment 10

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

Attachment: patch

Comment 11

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

Comment on attachment 8670703 [details] [diff] [review]
patch

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5f32388ee29f

Comment 12

[Karl Tomlinson (:karlt)]

Comment on attachment 8670703 [details] [diff] [review]
patch

(In reply to Martin Stránský from comment #9)
> This bug is caused by disabled double buffering on the mShell (outer) widget
> when mContainer has the rendering window and CSD is enabled. Karl, do we
> actually need to listen on visibility events for the mShell in that case? I
> think we don't need that.

I also don't think we need visibility events on mShell with CSD.

>+    bool            containerHasWindow = false;

This name is now a little confusing because it is false in the eWindowType_child/parentGtkContainer situation even though mContainer then has a window.  (It is also a bit confusing because the container can have subwindows from eWindowType_child nsWindows, which is why mContainer needs to be included here even when mGdkWindow belongs to mShell.)

Can you rename containerHasWindow to something like shellHasCSD, please?

Comment 13

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

Attachment: patch for check-in

Thanks, there's the updated one.

Comment 14

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

Comment on attachment 8672681 [details] [diff] [review]
patch for check-in

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8756bedb1769

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking since this sounds like a regression. Once it looks good on m-c, let's uplift this fix to aurora. It should not affect 43 (beta) right now since GTK is disabled there.

Comment 16

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4fabb51393c8

Comment 17

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

Comment on attachment 8672681 [details] [diff] [review]
patch for check-in

Approval Request Comment
[Feature/regressing bug #]: 1210249
[User impact if declined]: Artifacts around main Firefox window when it's moved/resized on Freya OS (CSD enabled).
[Describe test coverage new/current, TreeHerder]: no
[Risks and why]: low, we draw to MozContainer only so we should listen on draw events only there.
[String/UUID change made/needed]: no

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4fabb51393c8

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8672681 [details] [diff] [review]
patch for check-in

Fix for GTK3 issue; we should uplift this along with the patch in bug 1195002

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/08420d2c251a