Closed Bug 1195002 Opened 4 years ago Closed 4 years ago

titlebar overlaps chrome UI on Linux Elementary OS Freya / with GTK_CSD (Gtk3)

Categories

(Core :: Widget: Gtk, defect)

42 Branch
Unspecified
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox41 --- unaffected
firefox42 + unaffected
firefox43 + fixed
firefox44 --- fixed

People

(Reporter: jhonmike, Assigned: stransky)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(5 files, 5 obsolete files)

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
Severity: normal → critical
Severity: critical → normal
OS: Unspecified → Linux
Version: Trunk → 42 Branch
Summary: Error Interface Linux Elementary OS Freya → Broken UI of Firefox DE on Linux Elementary OS Freya
Are you running gtk3?
Component: Untriaged → Widget: Gtk
Flags: needinfo?(jhonmike)
Product: Firefox → Core
Thanks for adjustments, I do not speak English, I have helped!
Flags: needinfo?(jhonmike)
Could you test with about:config > gfx.xrender.enabled=true (restart FF) if it's to false.
Flags: needinfo?(jhonmike)
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 :(
dpkg -s libgtk-3-0|grep '^Version'

gives me:

Version: 3.14.15-0ubuntu1~14.04~ricotz1

So, GTK 3.14.15 I suppose
jhonmike, are you running Gtk3?
Does setting layers.offmainthreadcomposition.enabled to false and restarting help?
(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 ... :|
Active GTK, not solved anything
Flags: needinfo?(jhonmike)
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.
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?
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.
I'm having the same issue too.

Can I help ?
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.
Flags: needinfo?(contact)
Flags: needinfo?(jhonmike)
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 :)
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
Ty for the reg log. Well, Gtk3 issue. :)
Blocks: 1186003, gtk3
Flags: needinfo?(jhonmike)
Flags: needinfo?(contact)
Summary: Broken UI of Firefox DE on Linux Elementary OS Freya → Broken UI of Firefox DE on Linux Elementary OS Freya after enabling Gtk3
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
(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.
Mike, can you take a look at this? Thanks!
Flags: needinfo?(mh+mozilla)
That would be something for Karl or Andrew to look at.
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(karlt)
Flags: needinfo?(andrew)
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.
Flags: needinfo?(andrew)
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.
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.
Flags: needinfo?(karlt)
Attachment #8655736 - Flags: review?(karlt) → review-
GTK_CSD=0 workaround works for me on a 42.0a2 (2015-09-01).
+1 for this problem!
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.
Blocks: ship-gtk3
Summary: Broken UI of Firefox DE on Linux Elementary OS Freya after enabling Gtk3 → titlebar overlaps chrome UI on Linux Elementary OS Freya / with GTK_CSD (Gtk3)
Duplicate of this bug: 1187485
(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.
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?
Attachment #8659899 - Flags: feedback?(karlt)
(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.
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.
Attachment #8659899 - Flags: feedback?(karlt) → feedback+
Attached patch patch (obsolete) — Splinter Review
Draw and fetch events from MozContainer. Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d79ea9a20a53
Attachment #8659899 - Attachment is obsolete: true
Attachment #8660618 - Flags: review?(karlt)
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).
Attachment #8660618 - Flags: review?(karlt)
Attachment #8660618 - Flags: review-
Attachment #8660618 - Flags: feedback+
Attached patch patch v.2 (obsolete) — Splinter Review
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
Attachment #8660618 - Attachment is obsolete: true
Attachment #8661963 - Flags: review?(karlt)
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
Flags: needinfo?(stransky)
Attachment #8661963 - Flags: review?(karlt)
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.
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.
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.
Attached patch patch v.3Splinter Review
> 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.
Attachment #8661963 - Attachment is obsolete: true
Flags: needinfo?(stransky)
Attachment #8662936 - Flags: review?(karlt)
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.
Attachment #8662936 - Flags: review?(karlt) → review+
(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
Attached patch patch for check-in (obsolete) — Splinter Review
Thanks, there's the one for check-in.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f4ee1682337f
Attached patch patch for check-in (obsolete) — Splinter Review
Fixed try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f25946545d31
Attachment #8664165 - Attachment is obsolete: true
Keywords: checkin-needed
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.
Yeah, sorry.
Attachment #8664680 - Attachment is obsolete: true
Flags: needinfo?(stransky)
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/351b02a1cf9f
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Martin, we disabled GTK 3 in 42 but we will be happy to take an uplift to aurora
Assignee: nobody → stransky
Flags: needinfo?(stransky)
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.
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?
Flags: needinfo?(stransky) → needinfo?(martin)
(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).
Flags: needinfo?(martin)
Please use bug 1210249 to track the issue in comment 55.
Do you need this to uplift now, or would it be best to wait for the patch to land in bug 1210249?
Flags: needinfo?(stransky)
(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.
Flags: needinfo?(stransky)
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
Flags: needinfo?(stransky)
Flags: needinfo?(karlt)
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
Flags: needinfo?(stransky)
Flags: needinfo?(karlt)
Attachment #8665382 - Flags: approval-mozilla-aurora?
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.
Attachment #8665382 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.