Disable full CSD support for XFCE as it does not support GDK_DECOR_BORDER

RESOLVED FIXED in Firefox 59

Status

()

enhancement
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: stransky, Assigned: stransky)

Tracking

(Blocks 1 bug)

Trunk
mozilla59
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox59 fixed)

Details

Attachments

(2 attachments)

(Assignee)

Description

a year ago
Disable full CSD support for XFCE as it does not support GDK_DECOR_BORDER. GDK_DECOR_BORDER causes the titlebar is shown on XFCE.

Comment 1

a year ago
Does this apply even to latest gtk3-ported code (still only on git for now afaik)?
(Assignee)

Comment 2

a year ago
(In reply to mirh from comment #1)
> Does this apply even to latest gtk3-ported code (still only on git for now
> afaik)?

If you mean https://github.com/stransky/gecko-dev/tree/titlebar-csd it contains the same code as mozilla-central now.

Comment 4

a year ago
Lol, no. 
I was talking about *xfce* gtk3 version. https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html

And should that work (or even already work), a 'dumb' check just on the DE name would feel lame.
(Assignee)

Comment 5

a year ago
(In reply to mirh from comment #4)
> Lol, no. 
> I was talking about *xfce* gtk3 version.
> https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> 
> And should that work (or even already work), a 'dumb' check just on the DE
> name would feel lame.

Sorry, I do my best. Feel free to provide better patch here, experts are always welcome.

Comment 6

a year ago
mozreview-review
Comment on attachment 8930595 [details]
Bug 1419456 - Disable full CSD support for XFCE as it does not support GDK_DECOR_BORDER,

https://reviewboard.mozilla.org/r/201700/#review207348
Attachment #8930595 - Flags: review?(jhorak) → review+

Comment 7

a year ago
Pushed by stransky@redhat.com:
https://hg.mozilla.org/integration/autoland/rev/af8727e2028e
Disable full CSD support for XFCE as it does not support GDK_DECOR_BORDER, r=jhorak
(Assignee)

Updated

a year ago
Blocks: 1419460

Comment 8

a year ago
(In reply to Martin Stránský [:stransky] from comment #5)
> (In reply to mirh from comment #4)
> > Lol, no. 
> > I was talking about *xfce* gtk3 version.
> > https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> > 
> > And should that work (or even already work), a 'dumb' check just on the DE
> > name would feel lame.
> 
> Sorry, I do my best. Feel free to provide better patch here, experts are
> always welcome.

I hope I'm not ccing the wrong folks

Comment 9

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/af8727e2028e
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59

Comment 10

a year ago
(In reply to mirh from comment #4)
> I was talking about *xfce* gtk3 version.
> https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> 
> And should that work (or even already work), a 'dumb' check just on the DE
> name would feel lame.

I think this bug is related to bug 1417933 comment 23 (and 24 for that matter), where Martin notes that to make this work in other window managers will require client-side resizers.

So presumably this bug to disable it on Xfce is just temporary until that other work is finished, which may land at a later date and end up being a fallback for window managers that don't support GDK_DECOR_BORDER.

This is just speculation on my part, but that's how I'm seeing the current situation.

Comment 11

a year ago
Yeah, I had got that. 
Just indeed I wasn't sure on whether xfce in-progress gtk3 port was already good enough to works good with it, or not. 

But I would assume you'd need a version-based "blacklist" for every DE eventually.
(Assignee)

Comment 12

a year ago
(In reply to Azari from comment #10)
> (In reply to mirh from comment #4)
> > I was talking about *xfce* gtk3 version.
> > https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> > 
> > And should that work (or even already work), a 'dumb' check just on the DE
> > name would feel lame.
> 
> I think this bug is related to bug 1417933 comment 23 (and 24 for that
> matter), where Martin notes that to make this work in other window managers
> will require client-side resizers.
> 
> So presumably this bug to disable it on Xfce is just temporary until that
> other work is finished, which may land at a later date and end up being a
> fallback for window managers that don't support GDK_DECOR_BORDER.

Titlebar should be hiden when browser.tabs.drawInTitlebar is set on XFCE. But as the GDK_DECOR_BORDER fallback is not implemented yet you'll miss resizers on main window.
(Assignee)

Comment 13

a year ago
(In reply to Martin Stránský [:stransky] from comment #12)
> (In reply to Azari from comment #10)
> > (In reply to mirh from comment #4)
> > > I was talking about *xfce* gtk3 version.
> > > https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> > > 
> > > And should that work (or even already work), a 'dumb' check just on the DE
> > > name would feel lame.
> > 
> > I think this bug is related to bug 1417933 comment 23 (and 24 for that
> > matter), where Martin notes that to make this work in other window managers
> > will require client-side resizers.
> > 
> > So presumably this bug to disable it on Xfce is just temporary until that
> > other work is finished, which may land at a later date and end up being a
> > fallback for window managers that don't support GDK_DECOR_BORDER.
> 
> Titlebar should be hiden when browser.tabs.drawInTitlebar is set on XFCE.
> But as the GDK_DECOR_BORDER fallback is not implemented yet you'll miss
> resizers on main window.

Sorry, I you need to also set widget.allow-client-side-decoration before Bug 1420110 lands.

Comment 14

a year ago
(In reply to mirh from comment #11)
> Yeah, I had got that. 
> Just indeed I wasn't sure on whether xfce in-progress gtk3 port was already
> good enough to works good with it, or not. 

I'm not sure exactly how Xfce's window manager works, but since this is a WM-specific bug, they'd have had to change the window manager to add support for GDK_DECOR_BORDER; I would've imagined that the gtk3 work they are doing right now is more about porting their panel, settings app, and other applications to gtk3, since at the moment I don't think they're using gtk at all for the window manager, so they may not have any reason to modify it (at least not until the wayland port).

I guess someone would have to look at it, but by the time that version of Xfce is released, I imagine Bug 1420841 will have been fixed, since Xfce tends to have long dev cycles.
(In reply to Azari from comment #14)
> (In reply to mirh from comment #11)
> > Yeah, I had got that. 
> > Just indeed I wasn't sure on whether xfce in-progress gtk3 port was already
> > good enough to works good with it, or not. 
> 
> I'm not sure exactly how Xfce's window manager works, but since this is a
> WM-specific bug, they'd have had to change the window manager to add support
> for GDK_DECOR_BORDER; I would've imagined that the gtk3 work they are doing
> right now is more about porting their panel, settings app, and other
> applications to gtk3, since at the moment I don't think they're using gtk at
> all for the window manager, so they may not have any reason to modify it (at
> least not until the wayland port).

Thanks for taking the time to look into this and trying to make Firefox work the best on xfce, much appreciated.

I have just a couple of comments that, I hope, will help clarifying the current position.

Despite it's name (GDK_DECOR_BORDER), this is a Motif WM hint (MWH_HINTS), i.e. something like 20+ years old. MWM_HINTS allowed to define which part of the WM decorations should be drawn by the window manager, that included the title bar, resize frame, buttons, etc.

xfwm4 has support for this, but only partially (just like kwin actually), i.e. it doesn't decorrelate the titlebar from the rest of the frame, meaning it's all or nothing. One reason for this is that modern (as in supporting EWMH) X11 clients would define a semantic using NET_WM_WINDOW_TYPE and the window manager would remain in control on how to decorate the client window based on that semantic, so that the desktop remains consistent, as opposed to the older approach taken by Motif where the client would specify which bits of its decoration to draw, which led to all sorts of abuse and inconsistencies between applications.

Nowadays, apart from these older Motif applications, there is actually very seldom use for this anyway, client side decorations (CSD for short) is certainly not one of them. CSD means the client does all the work, it should not depend on the window manager for decorating /some/ of the frame. FWIW, gtk+ has support for this and is perfectly capable of doing CSD without it.

As for Wayland, this is an entirely different architecture, protocol, etc. which require a complete rewrite of a display server within the compositor, a tremendous amount of work, not something which is planned for xfce because we simply do not have the manpower for this, any time soon, if ever (the port of xfce to gtk3 is completely unrelated to Wayland, and being ported to gtk3 which has a gdk Wayland backend for the clients doesn't imply we magically get a Wayland compositor for free).

> I guess someone would have to look at it, but by the time that version of
> Xfce is released, I imagine Bug 1420841 will have been fixed, since Xfce
> tends to have long dev cycles.

So long story short, I reckon an X11 client willing to achieve client side decorations should draw *all* of the decorations, whereas one willing to remain with server side decorations should rely on the window manager for all of its decorations, and clients should not mix the two.
(Assignee)

Comment 16

a year ago
(In reply to Olivier Fourdan from comment #15)
> Nowadays, apart from these older Motif applications, there is actually very
> seldom use for this anyway, client side decorations (CSD for short) is
> certainly not one of them. CSD means the client does all the work, it should
> not depend on the window manager for decorating /some/ of the frame. FWIW,
> gtk+ has support for this and is perfectly capable of doing CSD without it.
> 
[...]
> 
> So long story short, I reckon an X11 client willing to achieve client side
> decorations should draw *all* of the decorations, whereas one willing to
> remain with server side decorations should rely on the window manager for
> all of its decorations, and clients should not mix the two.

Yes, I understand. What we want at Firefox is to have our own titlebar rendered by Firefox (by styles) and we don't care about the CSD shadows (borders, resizers) around the window. So we want Gtk to draw/handle CSD shadows/borders and resize the windows but don't draw GtkTitleBar widget. Is that possible? [1].

Also unfortunately Gtk is missing something like WM_NCHITTEST [2] which is used on Windows which also complicates things for us.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1420841#c2
[1] https://msdn.microsoft.com/cs-cz/library/windows/desktop/ms645618(v=vs.85).aspx
Flags: needinfo?(ofourdan)
Quality, including shadows, is dependent on _GTK_FRAME_EXTENTS and other things, but resizing is available even without _GTK_FRAME_EXTENTS.
Attachment #8932675 - Attachment mime type: text/x-c++src → text/plain
Where GDK_DECOR_BORDER works, I'm guessing it is better than GTK CSD, as it would provide a more native experience and avoid the usual CSD problems tracked at https://bugzilla.gnome.org/show_bug.cgi?id=729721
(I don't know whether or not there are enough systems where GDK_DECOR_BORDER works to justify supporting that configuration.)
(Assignee)

Comment 19

a year ago
(In reply to Karl Tomlinson (:karlt) from comment #18)
> Where GDK_DECOR_BORDER works, I'm guessing it is better than GTK CSD, as it
> would provide a more native experience and avoid the usual CSD problems
> tracked at https://bugzilla.gnome.org/show_bug.cgi?id=729721
> (I don't know whether or not there are enough systems where GDK_DECOR_BORDER
> works to justify supporting that configuration.)

I agree with you. This setup reliably works on gnome-shell and Cinamon which is IMHO majority of Gtk applications now as Ubuntu switched to gnome-shell at 17.10 (AFAIK). I didn't test Unity - adding to my TODO list.
(Assignee)

Comment 20

a year ago
(In reply to Karl Tomlinson (:karlt) from comment #17)
> Created attachment 8932675 [details]
> GTK CSD demo without titlebar
> 
> Quality, including shadows, is dependent on _GTK_FRAME_EXTENTS and other
> things, but resizing is available even without _GTK_FRAME_EXTENTS.

That's really great to see this working! I tested this approach some time ago and it didn't work - maybe I used wrong widget as the titlebar replacement.
(Assignee)

Comment 21

a year ago
(In reply to Karl Tomlinson (:karlt) from comment #17)
> Created attachment 8932675 [details]
> GTK CSD demo without titlebar
> 
> Quality, including shadows, is dependent on _GTK_FRAME_EXTENTS and other
> things, but resizing is available even without _GTK_FRAME_EXTENTS.

gtk_window_set_titlebar() works only for unrealized widget which complicates it. We may need to enable that early or unrealize mShell on the fly. The latter (if implemented) needs extra care as Gtk tends to unrealize mContainer and hide the main toplevel window.
(Assignee)

Updated

a year ago
Blocks: 1421974
(Assignee)

Comment 22

a year ago
gtk_window_set_titlebar() solution filed as Bug 1421974
(Assignee)

Updated

a year ago
Flags: needinfo?(ofourdan)
You need to log in before you can comment on or make changes to this bug.