Closed Bug 1210249 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: Widget: Gtk, defect)

44 Branch
Unspecified
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox43 + fixed
firefox44 + fixed

People

(Reporter: karlt, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

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).
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.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(martin)
Summary: titlebar overlaps chrome UI on Linux Elementary OS Freya / with GTK_CSD (Gtk3) → Linux Elementary OS Freya doesn't redraw background apps when moving Firefox window
Other GTK3 applications and the file open dialog not cause the issue.
(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.
Flags: needinfo?(martin)
(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.
Yes, I can see that on Freya OS.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> 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).
BTW. setting GTK_CSD=1 makes such frames on Fedora too. So seems to a general issue.
Summary: Linux Elementary OS Freya doesn't redraw background apps when moving Firefox window → set GTK_CSD=1 doesn't redraw background apps when moving Firefox window
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).
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.
Flags: needinfo?(karlt)
Attached patch patchSplinter Review
Attachment #8670703 - Flags: review?(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?
Flags: needinfo?(karlt)
Attachment #8670703 - Flags: review?(karlt) → review+
Thanks, there's the updated one.
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 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
Attachment #8672681 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/4fabb51393c8
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
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
Attachment #8672681 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.