jhonmike Reporter
	Description • 9 years ago

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36

Steps to reproduce:

Update


Actual results:

Image

	Loic
	Comment 1 • 9 years ago

Are you running gtk3?

	jhonmike Reporter
	Comment 2 • 9 years ago

Thanks for adjustments, I do not speak English, I have helped!

	Loic
	Comment 3 • 9 years ago

Could you test with about:config > gfx.xrender.enabled=true (restart FF) if it's to false.

	eboyee
	Comment 4 • 9 years ago

I'm having this issue too.

gfx.xrender.enabled was already set to true. I tried setting it to false and true, same behavior.

What else can I try? I really miss the Dev Edition. Had to purge it and switch back to beta :(

	eboyee
	Comment 5 • 9 years ago

dpkg -s libgtk-3-0|grep '^Version'

gives me:

Version: 3.14.15-0ubuntu1~14.04~ricotz1

So, GTK 3.14.15 I suppose

	Loic
	Comment 6 • 9 years ago

jhonmike, are you running Gtk3?

	Karl Tomlinson (:karlt)
	Comment 7 • 9 years ago

Does setting layers.offmainthreadcomposition.enabled to false and restarting help?

	eboyee
	Comment 8 • 9 years ago

(In reply to Karl Tomlinson (ni?:karlt) from comment #7)
> Does setting layers.offmainthreadcomposition.enabled to false and restarting
> help?

Nope, still the same. It seems like FF does not have any UI, the titlebar covers the tabs and there is no shadow etc.

Even the profile manager does not show normally.

I think ElementaryOS team tweaked the GTK in some way that makes this bug ... :|

	jhonmike Reporter
	Comment 9 • 9 years ago

Active GTK, not solved anything

	Daniele Di Minica
	Comment 10 • 9 years ago

It happens to me too and the two above settings are not helping.
Same Linux distro, same GTK version.

It seems an issue with Firefox's attempt to remove the elementaryOS title bar. When I can click on the "maximize" button, Firefox will normally go to maximized state and seems to work better. It remains the issue with the titlebar: Firefox tries to draw the tabs in its place but elementary tries to draw the standard titlebar again. I think that Chrome manages this problem in the "Use system title bar and borders" setting.

	Karl Tomlinson (:karlt)
	Comment 11 • 9 years ago

Firefox doesn't ask for the titlebar to be removed unless in fullscreen mode, but perhaps GTK is requesting this.  Are there any other GTK3 apps (evince perhaps)?  How do they look?

	Daniele Di Minica
	Comment 12 • 9 years ago

Evince looks perfect in elementaryos and has the search box and navigation buttons integrated inside the title bar. All the other application I tried to use in eos don't have this issue.

	contact
	Comment 13 • 9 years ago

I'm having the same issue too.

Can I help ?

	Loic
	Comment 14 • 9 years ago

Well, as it's probably a regression in Firefox, I guess it's time to use the tool Mozregression to find a possible regression range.
See http://mozilla.github.io/mozregression/ for details about install and usage.

If FF 39 (or 38) was fine on your Elementary OS Freya, just run the command "mozregression --good-release 39" and paste here the pushlog provided in the console output (no need to bisect).

It would be useful to have 2 users running Mozreg to see if the regression range are similar in both cases.

	eboyee
	Comment 15 • 9 years ago

I ran

mozregression --good-release 41

as 41b0.3 is the version that I'm using at the moment and is the last version that works.

Here's the pushlog:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1ee54e043b9b&tochange=939320b957c5

btw, very interesting tool :)

	Daniele Di Minica
	Comment 16 • 9 years ago

Same pushlog here for me:

25:08.82 LOG: MainThread Bisector INFO Last good revision: 1ee54e043b9b
25:08.82 LOG: MainThread Bisector INFO First bad revision: 939320b957c5
25:08.82 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1ee54e043b9b&tochange=939320b957c5

	Loic
	Comment 17 • 9 years ago

Ty for the reg log. Well, Gtk3 issue. :)

	Daniele Di Minica
	Comment 18 • 9 years ago

Is it something that will be fixed in the next firefox releases or we need to wait for a Gtk3 patch?
Still happens in the latest updates of these days.

thanks

	eboyee
	Comment 19 • 9 years ago

(In reply to Daniele Di Minica from comment #18)
> Is it something that will be fixed in the next firefox releases or we need
> to wait for a Gtk3 patch?
> Still happens in the latest updates of these days.
> 
> thanks

As I can see, nobody is assigned to this. I suppose that none of the devs are willing to switch distro because of the bug. So who knows when this will be fixed. My only hope is that it will be fixed before entering the stable release.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 20 • 9 years ago

Mike, can you take a look at this? Thanks!

	Mike Hommey [:glandium]
	Comment 21 • 9 years ago

That would be something for Karl or Andrew to look at.

	Andrew Comminos [:acomminos]
	Comment 22 • 9 years ago

It looks like this is caused by the way elementary OS deals with windows without client-side decorations- the issue can be worked around by setting the environment variable GTK_CSD=0. I'd wager that our drawing code violates elementary OS's window manager's expectations of windows without CSD, I'll look into this some more and see if there's anything we can do.

	Andrew Comminos [:acomminos]
	Comment 23 • 9 years ago

Okay, I can reproduce with GTK_CSD=1 on a Debian unstable system with GTK 3.16. Seems like the cause is as simple as us drawing directly into the GdkWindow, ignoring the bounds of the decorations drawn by GTK; we should perhaps consider forcing GTK_CSD=0 for now and consider supporting GTK's client side decorations later.

	Karl Tomlinson (:karlt)
	Comment 25 • 9 years ago

Comment on attachment 8655736 [details] [diff] [review]
Force GTK3 client side decorations off.

This would turn off CSD for child processes, spawned to handle downloaded
files for example, and I don't think we want to do that.

We could set the environment variable temporarily at the right, and restore
any previous value.  I guess we don't fork children on other threads.

The bug could probably be resolved with appropriate offsets for drawing surfaces and event handling, but that is not going to work with glXSwapBuffers.

Another option could be to give MozContainer its own window when the GtkWindow
is doing CSD.  I don't see a simple way to query for CSD, but it can be obtained
from GTK_IS_HEADER_BAR() on the children from gtk_container_forall on the
GtkWindow.  Checking the GTK_CSD env var is probably good enough for now.  Or
perhaps the visual can be checked for an alpha channel depending on the need
for 1191184.  This approach might be better than disabling CSD (but I'm happy with the other as an interim solution).  It can give the app an opaque window for drawing and window manager occlusion culling.  I don't know whether or not there would be any observable difference in behavior between CSD and WMSD, but I guess there must be or there would be no point in having CSD.  Which GtkWidget receives events might change for some events, when the widgets have different windows, but I expect that would be fixable.

	Daniele Di Minica
	Comment 26 • 9 years ago

GTK_CSD=0 workaround works for me on a 42.0a2 (2015-09-01).

	William de Oliveira
	Comment 27 • 9 years ago

+1 for this problem!

	eboyee
	Comment 28 • 9 years ago

I did export GTK_CSD=0 and modified the firefox.desktop to load with gtk3-nocsd.so like in this example:

http://www.webupd8.org/2014/08/how-to-disable-gtk3-client-side.html

It even look better and more part of the OS if you ask me.

	Rui Matos
	Comment 30 • 9 years ago

(In reply to Karl Tomlinson (ni?:karlt) from comment #25)
> Another option could be to give MozContainer its own window when the
> GtkWindow
> is doing CSD.  I don't see a simple way to query for CSD, but it can be
> obtained
> from GTK_IS_HEADER_BAR() on the children from gtk_container_forall on the
> GtkWindow.

Since you draw directly to the underlying X window I think you should do this unconditionally. In

http://hg.mozilla.org/mozilla-central/file/c0abc2a6e11f/widget/gtk/nsWindow.cpp#l3626

you get the GdkWindow for the toplevel widget. Couldn't you instead use the GdkWindow for the toplevel's child which you create a few lines earlier? That one should have all the correct offsets already setup.


BTW, unrelated, but reading that code I noticed http://hg.mozilla.org/mozilla-central/file/c0abc2a6e11f/widget/gtk/nsWindow.cpp#l3833 which is pointless right now since mGdkWindow is the toplevel which is obviously always backend by a native X window.

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 31 • 9 years ago

This is very rough patch for the GdkWindow inside MozContainer. The problem here is with keyboard/mouse input events and popup windows.

gtk_grab_add(mShell) is used by nsWindow::CaptureRollupEvents() and focus code which means that:

- both MozContainer and mShell must listen events targeted to eventWidget
- mEventWidget should be a member of nsWindow and replaces mShell in gtk_grab_add() and similar.

I'm not sure how the focus handling is affected by this change. I guess the second approach would be cleaner, right?

	Karl Tomlinson (:karlt)
	Comment 32 • 9 years ago

(In reply to Rui Matos from comment #30)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #25)
> > Another option could be to give MozContainer its own window when the
> > GtkWindow
> > is doing CSD.

> Since you draw directly to the underlying X window I think you should do
> this unconditionally. In
> 
> http://hg.mozilla.org/mozilla-central/file/c0abc2a6e11f/widget/gtk/nsWindow.
> cpp#l3626
> 
> you get the GdkWindow for the toplevel widget. Couldn't you instead use the
> GdkWindow for the toplevel's child which you create a few lines earlier?

Creating a GdkWindow also for that child widget is the proposal for when GTK is choosing CSD, but it is unnecessary to use another window with WMSD.

Given the effort that went into GDK client-side windows, I assume that extra windows come with a cost. gtk_widget_set_app_paintable() and gtk_widget_set_double_buffered() are used to prevent GTK from drawing to the window.

> That one should have all the correct offsets already setup.

Yes, but no offsets are required with WMSD.

> BTW, unrelated, but reading that code I noticed
> http://hg.mozilla.org/mozilla-central/file/c0abc2a6e11f/widget/gtk/nsWindow.
> cpp#l3833 which is pointless right now since mGdkWindow is the toplevel
> which is obviously always backend by a native X window.

I think some nsWindows are still created with type eWindowType_child.

This code looks completely unnecessary and the comment doesn't explain why it
is there, but it was added for bug 1194397.

	Karl Tomlinson (:karlt)
	Comment 33 • 9 years ago

Comment on attachment 8659899 [details] [diff] [review]
WIP - concept of MozContainer with GdkWindow

>         // These events are sent to the owning widget of the relevant window
>         // and propagate up to the first widget that handles the events, so we
>         // need only connect on mShell, if it exists, to catch events on its
>         // window and windows of mContainer.
>+

I wondered for a bit why we couldn't depend on this to listen to these events
on only the outer (mShell) widget, but I think you are right in making the container the event window because the events on the decoration window are not events that Gecko should be acting on. 

(In reply to Martin Stránský from comment #31)
> The problem
> here is with keyboard/mouse input events and popup windows.
> 
> gtk_grab_add(mShell) is used by nsWindow::CaptureRollupEvents()

Thanks for identifying this.

> and focus code

I don't know what focus code is affected here.

> which means that:
> 
> - both MozContainer and mShell must listen events targeted to eventWidget
> - mEventWidget should be a member of nsWindow and replaces mShell in
> gtk_grab_add() and similar.
> 
> I'm not sure how the focus handling is affected by this change. I guess the
> second approach would be cleaner, right?

I think listening for events on only one "eventWidget" is the right thing to
do because we don't want Gecko to act on events on the decoration window. 

I think gtk_grab_add() can be called on the mContainer instead of mShell
if the key event signal handlers return TRUE to avoid bug 707623.
I'm not aware of any remaining applications embedding Gecko, but I think we
can find a solution if it turns out to be necessary.

Are there other places where mShell is currently used but mContainer would not
be appropriate?

>+        gtk_widget_set_app_paintable(GTK_WIDGET(mContainer), TRUE);

AFAIK this has no effect on the MozContainer widget.

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 34 • 9 years ago

Draw and fetch events from MozContainer. Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d79ea9a20a53

	Karl Tomlinson (:karlt)
	Comment 35 • 9 years ago

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

>-    if (!mShell)
>+    GtkWidget *widget = GetMozContainerWidget();
>+    if (!widget)
>         return NS_ERROR_FAILURE;
> 
>     if (aCapture) {
>-        gtk_grab_add(mShell);
>+        gtk_grab_add(widget);
>         GrabPointer(GetLastUserInputTime());
>     }
>     else {
>         ReleaseGrabs();
>-        gtk_grab_remove(mShell);
>+        gtk_grab_remove(widget);

Just use mContainer.
We don't need to support capture on child windows.

Similarly in CaptureRollupEvents().

>-        // Use mShell's window for drawing and events.
>-        gtk_widget_set_has_window(container, FALSE);
>-        eventWidget = mShell;
>+
>+        // Use container's window for drawing and events.
>+        eventWidget = container;

Please make this conditional on whether GTK is using CSD.
Those with WMSD don't need the extra window.
See comment 25 for options re determining whether CSD is in use.

I suspect gtk_widget_set_app_paintable() should not be called on mShell when
using CSD (but that need not be part of this patch).

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 36 • 9 years ago

Thanks, there's an updated one. Note that the "solid-csd" is a bit unofficial - it's used for decorations when alpha blending is not supported (see gtk_window_enable_csd() from gtkwindow.c:4077)

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

	Karl Tomlinson (:karlt)
	Comment 37 • 9 years ago

Comment on attachment 8661963 [details] [diff] [review]
patch v.2

Sorry if I wasn't clear, but what I meant was to make only eventWidget,
gtk_widget_set_has_window, and gtk_widget_set_app_paintable
conditional on CSD.

>+    GtkWidget *widget = mHasWindowContainer ? GTK_WIDGET(mContainer) : mShell;
>+    if (!widget)

GTK_WIDGET(mContainer) should be fine in the capture methods even without CSD.
It was before bug 707623 anyway.  Does that still work?

>@@ -3091,17 +3089,19 @@ nsWindow::OnKeyPressEvent(GdkEventKey *a

>     // If the event was consumed, return.
>     if (status == nsEventStatus_eConsumeNoDefault) {
>         return TRUE;
>     }
> 
>-    return FALSE;
>+    // When drawing to MozContainer window stop
>+    // key event propagation
>+    return mHasWindowContainer;
> }

>@@ -3114,17 +3114,19 @@ nsWindow::OnKeyReleaseEvent(GdkEventKey 

>     // If the event was consumed, return.
>     if (status == nsEventStatus_eConsumeNoDefault) {
>         return TRUE;
>     }
> 
>-    return FALSE;
>+    // When drawing to MozContainer window stop
>+    // key event propagation
>+    return mHasWindowContainer;
> }

Return FALSE regardless here.
I don't think this needs to be dependent on CSD.
That means the nsEventStatus_eConsumeNoDefault test
and the mHasWindowContainer member are not necessary.

>+        // Prevent GtkWindow from painting a background to flicker.
>+        gtk_widget_set_app_paintable(eventWidget, TRUE);

This need only be called when eventWidget is mShell.  It's harmless on the
container, but it would be clearer to do it only when not CSD.

>+#if GTK_CHECK_VERSION(3,14,0)
>+        // We can't draw directly to top-level window when client side
>+        // decorations are enabled. We use container with GdkWindow instead.
>+        GtkStyleContext* style = gtk_widget_get_style_context(mShell);
>+        mHasWindowContainer = gtk_style_context_has_class(style, GTK_STYLE_CLASS_CSD);
>+        if (!mHasWindowContainer) {
>+            mHasWindowContainer = gtk_style_context_has_class(style, "solid-csd");
>+        }
>+#endif

This is nice and simple, but doesn't mShell need to be realized first for this
detection to work (contrary to most GTK style context setup)?

Please use "csd" instead of GTK_STYLE_CLASS_CSD so that this will work with
builds against earlier GTK versions.

It's not actually necessary to check for solid-csd because that is only on the
style context if gtk_window_set_titlebar has been called explicitly, which
won't happen for this window.  Otherwise enabling csd depends on
use_client_shadow.

https://git.gnome.org/browse/gtk+/tree/gtk/gtkwindow.c?id=3.16.6#n5809

	Alexander Larsson
	Comment 38 • 9 years ago

As the person responsible for implementing client-side windows in gtk, please don't be afraid of using an extra subwindow. There is no real cost in this (while having each button in the window have its own window will cause tearing on resize). The correct way to handle custom drawing with gtk is to put a custom widget as a child of the GtkWindow and do everything in that, rather than draw over the toplevel GtkWindow that gtk draws to. Libreoffice does gtk3 it this way too. Anything else will be a constant fight against the internals of gtk that risk breaking as things change.

	Karl Tomlinson (:karlt)
	Comment 39 • 9 years ago

Hmm.  Using a child window gave a problems like bug 793501.
That was fixed by not using a child window, but has since already regressed.
I'm not sure what caused it to regress, but it may have been off main thread compositing.  It doesn't reproduce every time.

Are child windows resized synchronously when the toplevel is resized?
Gecko resize response has also regressed, but I'm interested in whether it is theoretically possible to get this right.

	Alexander Larsson
	Comment 40 • 9 years ago

Not sure what you mean by synchronously, but the window manager is not involved with child window resizes, so we need not do any weird configurenotify roundtrip. When we get a configure-notify for the GtkWindow and the size has changed we queue a resize on the toplevel, which will trigger a layout cycle, calculating all the sizes of child widgets, which are then applied and we redraw the frame and push it. This cycle is tied to the frame clock, so i guess there could be some time before it is done. We generally map our windows initially bg-none though so nothing should be visible until we actually draw the contents.

I guess this is problematic for firefox, as it is not synced to the same frame clock, as it will create a child window without bg none, and start drawing to it earlier.

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 41 • 9 years ago

> Return FALSE regardless here.
> I don't think this needs to be dependent on CSD.
> That means the nsEventStatus_eConsumeNoDefault test
> and the mHasWindowContainer member are not necessary.

You mean TRUE to stop the event propagation, right? Otherwise the key input is doubled in panel like in Bug 707623.

> GTK_WIDGET(mContainer) should be fine in the capture methods even without CSD.
> It was before bug 707623 anyway.  Does that still work?

Yes, but only when OnKeyPressEvent/OnKeyReleaseEvent returns TRUE and terminates the event propagation.

> This is nice and simple, but doesn't mShell need to be realized first for this
> detection to work (contrary to most GTK style context setup)?

correct, updated the patch for explicit realize of mShell.

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 42 • 9 years ago

Comment on attachment 8662936 [details] [diff] [review]
patch v.3

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

	Karl Tomlinson (:karlt)
	Comment 43 • 9 years ago

Comment on attachment 8662936 [details] [diff] [review]
patch v.3

Thanks, Martin.
Just need to keep things working for GTK 2.

>+        // "csd" style is set when widget is realized so we need to call
>+        // it explicitly now.
>+        gtk_widget_realize(mShell);
>+
>+        // We can't draw directly to top-level window when client side
>+        // decorations are enabled. We use container with GdkWindow instead.
>+        GtkStyleContext* style = gtk_widget_get_style_context(mShell);
>+        bool hasWindowContainer = gtk_style_context_has_class(style, "csd");

Please call this containerHasWindow, to be clearer, or "hasCSD".

If you add

#if (MOZ_WIDGET_GTK == 2) 
        bool containerHasWindow = false;
#else

then the lines quoted above can be all in an else block.

	Karl Tomlinson (:karlt)
	Comment 44 • 9 years ago

(In reply to Alexander Larsson from comment #40)
> Not sure what you mean by synchronously, but the window manager is not
> involved with child window resizes, so we need not do any weird
> configurenotify roundtrip. When we get a configure-notify for the GtkWindow
> and the size has changed we queue a resize on the toplevel, which will
> trigger a layout cycle, calculating all the sizes of child widgets, which
> are then applied and we redraw the frame and push it. This cycle is tied to
> the frame clock, so i guess there could be some time before it is done. We
> generally map our windows initially bg-none though so nothing should be
> visible until we actually draw the contents.
> 
> I guess this is problematic for firefox, as it is not synced to the same
> frame clock, as it will create a child window without bg none, and start
> drawing to it earlier.

Thanks for your comments, Alexander.

I hadn't caught up with the _NET_WM_SYNC_REQUEST changes in GTK [1] but gather
that "synchronously" is no longer a requirement now.

If child widgets are resized and sent expose signals before the
_NET_WM_SYNC_REQUEST reply is sent then that should give Gecko a chance to
draw with window managers supporting the new _NET_WM_SYNC_REQUEST [2].

For older window managers, there may still be the issues of unsynchronized
mapping of windows.  I'm not clear how much the situation has improved there,
so feel safer sticking with the current strategy where practical until this is
clear.

[1] https://git.gnome.org/browse/gtk+/commit/?id=645b5f398d2d50c361600f4f8a089488a66eed99
[2] https://mail.gnome.org/archives/wm-spec-list/2013-January/msg00000.html

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 45 • 9 years ago

Thanks, there's the one for check-in.

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

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 46 • 9 years ago

Fixed try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f25946545d31

	Pulsebot
	Comment 47 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/1f327c67db57

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 48 • 9 years ago

I had to back this out in https://hg.mozilla.org/integration/mozilla-inbound/rev/44004b0d91bd for being the likely cause of ASAN/mulet tests failing like https://treeherder.mozilla.org/logviewer.html#?job_id=14582982&repo=mozilla-inbound

	Karl Tomlinson (:karlt)
	Comment 49 • 9 years ago

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

>+        if (!containerHasWindow) {
>+            // Use mShell's window for drawing and events.
>+            gtk_widget_set_has_window(container, FALSE);
>+            // Prevent GtkWindow from painting a background to flicker.
>+            gtk_widget_set_app_paintable(mShell, TRUE);
>+        }
>+#endif

Move the #endif to before the block, after the code quoted in comment 43.

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 50 • 9 years ago

Yeah, sorry.

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 51 • 9 years ago

Comment on attachment 8665382 [details] [diff] [review]
patch for check-in v.3

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

	Pulsebot
	Comment 52 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/351b02a1cf9f

	Carsten Book [:Tomcat]
	Comment 53 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/351b02a1cf9f

	Sylvestre Ledru [:Sylvestre]
	Comment 54 • 9 years ago

Martin, we disabled GTK 3 in 42 but we will be happy to take an uplift to aurora

	Martin Giger [:freaktechnik]
	Comment 55 • 9 years ago

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.

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 56 • 9 years ago

Sylvestre, I don't have strong opinion here. May we uplift together with a fix for comment 55?

Martin, which system do you run, how can I reproduce that? It is the Feya OS or some Ubuntu version?

	Martin Giger [:freaktechnik]
	Comment 57 • 9 years ago

(In reply to Martin Stránský from 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).

	Karl Tomlinson (:karlt)
	Comment 58 • 9 years ago

Please use bug 1210249 to track the issue in comment 55.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 59 • 9 years ago

Do you need this to uplift now, or would it be best to wait for the patch to land in bug 1210249?

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 60 • 9 years ago

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #59)
> Do you need this to uplift now, or would it be best to wait for the patch to
> land in bug 1210249?

Feel free to uplift it now and bug 1210249 and bug 1209659 after that. It does not matter actually but this one has to be checked in first.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 61 • 9 years ago

Sorry for the back and forth delay, but, can you request approval on the patches that need uplift? There is an approval request flag which you can set to "?" if you view the patch details. Karl maybe you can do this for Martin if he's not around

	Martin Stránský [:stransky] (ni? me) Assignee
	Comment 62 • 9 years ago

Comment on attachment 8665382 [details] [diff] [review]
patch for check-in v.3

Approval Request Comment
[Feature/regressing bug #]: #1195002
[User impact if declined]: Broken UI rendering when CSD is enabled (Freya OS)
[Describe test coverage new/current, TreeHerder]: no tests
[Risks and why]: low, the window rendering change is active only on systems with CSD enabled, although modified keyboard input widget affects all systems.
[String/UUID change made/needed]: no

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 63 • 9 years ago

Comment on attachment 8665382 [details] [diff] [review]
patch for check-in v.3

GTK3 fix, has been on m-c for a couple of weeks. 
Approved for uplift to aurora.

	Carsten Book [:Tomcat]
	Comment 64 • 9 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/203e5d3c06ba