Last Comment Bug 513159 - [Linux/Gnome] Drawing in the Title Bar for the new Firefox theme
: [Linux/Gnome] Drawing in the Title Bar for the new Firefox theme
Status: ASSIGNED
[Australis:M-], tpi:+
:
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: Trunk
: x86 Linux
: P4 normal with 46 votes (vote)
: ---
Assigned To: Andrew Comminos [:acomminos] (back to classes, will be slow)
:
:
Mentors:
: 644160 702817 729460 958811 1109648 1118521 1234433 1258969 1279960 1296314 (view as bug list)
Depends on: gtk3 900740 1283299
Blocks: platform-ui-team 513157 546831 572312
  Show dependency treegraph
 
Reported: 2009-08-27 18:16 PDT by Alex Faaborg [:faaborg] (Firefox UX)
Modified: 2016-11-22 01:45 PST (History)
117 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Chrome's blend with gnome-panel (291.45 KB, image/png)
2010-04-21 03:49 PDT, Peter Henkel [:Terepin]
no flags Details
GNOME-Shell App Menu (96.61 KB, image/png)
2010-07-29 09:28 PDT, Michael Monreal [:monreal]
no flags Details
No title bar when maximized. Opt-in feature of GNOME 3.4. (27.31 KB, image/png)
2011-12-27 06:28 PST, alexhultman
no flags Details
Shell menu (32.48 KB, image/png)
2011-12-27 11:11 PST, alexhultman
no flags Details
Windows vs Linux theming, not maximized (333.83 KB, image/png)
2011-12-27 17:07 PST, alexhultman
no flags Details
Top is current, bottom is my customized version with Hide Caption Title Bar Plus (36.25 KB, image/png)
2015-01-07 10:10 PST, Terrell Kelley
no flags Details

Description Alex Faaborg [:faaborg] (Firefox UX) 2009-08-27 18:16:08 PDT
This is the Linux version of bug 513157, details on the rational can be found in
bug 513157 comment #0, or below.

For Firefox 4, there are a variety of reasons why we will need to either draw
in the title bar of the application window, or actually draw the title bar
entirely from scratch:

1) Having a control at the edge of the window frame to set the active Weave
account.

2) Drawing a persona throughout all of chrome (including the title bar).

3) In private browsing mode changing the appearance of the theme, including the
title bar.  Interactively this is to reduce the number of mode errors (a
darkened theme is easily viewable using peripheral vision).  On a more
emotional and design level, it just looks really cool.

4) Placing tabs slightly into the area of the title bar will help us free up
space for the content area.
Comment 1 Benjamin Smedberg [:bsmedberg] 2009-08-27 18:26:21 PDT
Per today's discussion, this is complicated by the fact that Linux has multiple Window managers and it's harder for us to disable the standard windowmanager behavior and emulate it locally. We may be able to do this only for known targeted environments, and maybe we can ask gnome-peoples for help.
Comment 2 Zack Weinberg (:zwol) 2009-08-27 18:38:08 PDT
I think we're going to have to talk to the Gnome people (specifically, the Clutter/Mutter people: http://clutter-project.org/ ) about a way to do this *well*, and we should have a fallback design so that we don't look like **** when we can't do it at all.
Comment 3 Victor Bielawski 2009-10-08 10:04:16 PDT
Chromium implements a custom title bar on Linux which can be turned off.

http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/browser_titlebar.cc?view=markup
Comment 4 Alex Faaborg [:faaborg] (Firefox UX) 2010-02-09 17:11:34 PST
If we implemented a custom toolbar, can we access the window controls for the current Gnome theme so that they match?

We need to start getting this bug figured out. If Chrome on Linux, and Firefox and Windows are both featuring streamlined interfaces, while Firefox on Linux doesn't see any noticeable change between versions, Linux users are going to (rightfully so) feel like we ignored them for a major release.*

*under the assumption that we can't deploy the new theme in anything other than a major release, although we don't currently know when that will actually happen.
Comment 5 forfun93 2010-02-12 19:08:01 PST
(In reply to comment #4)
> If we implemented a custom toolbar, can we access the window controls for the
> current Gnome theme so that they match?
> 
Should carry on with GTK theme. Like the rest of the theme.
Comment 6 Michael Ventnor 2010-02-17 18:41:29 PST
There are a lot of things you can't access purely because of the large depth of things that themes can do. I personally believe going for a new shiny one-for-all theme is futile on Linux and that most people are happy with the native theme support we already give (although updating our library usage would certainly help...)

What Chromium does is it sets up a fake metacity widget and gets all its colour info off of that. That's certainly an...interesting way of doing it.
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/gtk_theme_provider.cc?view=markup
Comment 7 Michael Ventnor 2010-02-17 19:02:28 PST
There are numerous other problems with this route such as difficulty in replicating the buttons and the order of the buttons, and us not supporting the context menu which is used by some people for things like switching desktops.

I'm a little bemused at Chromium's approach, I don't know if it even works for people that don't use Metacity or Compiz as their window manager.
Comment 8 Karl Tomlinson (:karlt) 2010-02-17 19:20:41 PST
I expect that getting buttons in the right places, responding appropriately to mouse events on the title bar, and providing the appropriate context menu on the window decorations is going to be difficult if these are done client-side.

One thing to investigate would be the APIs to theme engines for the window managers.  They probably differ for each window manager, and I don't know whether they are really suitable for client-side use.

GTK is developing support for client-side decorations, which is expected to be in GTK+ 3 (which will be incompatible with GTK+ 2).
http://git.gnome.org/browse/gtk+/?h=client-side-decorations

Though Evan Martin doesn't sound convinced that this is going to solve the problems.
http://www.mail-archive.com/chromium-dev@googlegroups.com/msg09589.html
Comment 9 Peter Henkel [:Terepin] 2010-04-21 03:49:20 PDT
Created attachment 440454 [details]
Chrome's blend with gnome-panel

It will be:
1. Eye candy
2. Space saving
if upper edge of window blends with gnome-panel, when tabs are drawed in titlebar.
Comment 10 Alex Faaborg [:faaborg] (Firefox UX) 2010-04-21 10:38:20 PDT
That's pretty cool, I wonder if we should try to do the same thing when maximized.  We would need to merge "browser level" controls onto the tab strip, which we are already considering for maximized mode on Windows (things like an optional Firefox button, weave user account, possible full screen window control for netbooks).
Comment 11 Peter Henkel [:Terepin] 2010-04-21 10:43:52 PDT
Note that Chrome isn't drawing in titlebar to achive this. I have simply used Radiance theme and disabled titlebar, so what you see on screenshot is only tab bar.
Comment 12 Peter Henkel [:Terepin] 2010-04-28 02:00:18 PDT
Brighter days are coming, especially for FX, since it will be easier to draw in titlebar (read: it will be same as on Mac):
http://www.markshuttleworth.com/archives/359
Comment 13 Cork 2010-07-07 02:34:10 PDT
*** Bug 577228 has been marked as a duplicate of this bug. ***
Comment 14 Michael Monreal [:monreal] 2010-07-13 03:56:11 PDT
Ok, back from the summit where we had *a lot* of talks regarding this issue, discussing various ways to solve it.

There are basicly two options here: we try to get the unified look on all platforms or we leave the Linux port behind for Fx4[.0]...

Talking to Andreas Nilsson, we first concluded that a minimal approach would be fine for 4.0, e.g. having the ability to hide the menu while still keeping the window manager's window deco. This approach requires a menu button somewhere. We hacked together a prototype which draws a "Firefox" menu button in the tab bar, right in front of the first tab (similar to what you get on WinXP right now and what the latest Opera does). Pro: more vertical space because the menu bar is gone. Contra: less vertical space is saved compared to the approach taken on Win7 and you lose about one tab. Another option would be to have a Chrome-like button, which would go to the right side of the toolbar. Problem with that is that this would be quite different from other platforms and not help with "Firefox identity".

Which brings us to the second option: implementing the intended look as in the mockup.

The "simple" way to do this is setting a window hint to make the window manager skip drawing the window deco and implement it ourselves. This is what Chrome does right now and what XMMS does for at least a decade. It is impossible to match the native theme (shape of window buttons, special patterns) this way but it kind of works fine for the apps mentioned. A bigger problem is the lack of window manager interaction (right-click menu for moving window etc).

The "right" way to do it would be GTK3's client-side window-decoration¹ API. This basicly allows to draw the same window deco as drawn by Metacity/Mutter/Compiz, just doing it client side and allowing for modifications like adding buttons etc. Using this would solve a lot of problems and provide the best end-result for both Firefox' cross-platform identity and the user. However:
- GTK3 is not final yet, it will be released on Aug 30
- The CSWD API is not even part of the 3.0 branch yet. GTK developers have hinted that it will make it in, if there is need for it.
- Using that API means the whole app needs to be ported to GTK3. I don't know how much 2.x-only API is used in Firefox right now, but a port needs to be done at some point anyway. For example, Firefox still uses the glib2-only gnome-vfs library which is unmaintained and deprecated for multiple years now.

A decision has to be made at some point, soon. Keep in mind that the annual GNOME developer conference GUADEC¹ will be held in 2 weeks which may be the ideal place to recruit a few GNOME hackers to help with GTK3/CSWD as well as the Firefox GTK3 port.

[1] http://live.gnome.org/GTK+/ClientSideDecorations
[2] http://www.guadec.org/
Comment 15 Peter Henkel [:Terepin] 2010-07-13 04:05:25 PDT
If we will take the "right" way, we can exclude this feature from 4.0 and include it, for example, in 4.1. Tha same approach took TB developers and TB 3.1 was out only "few" months after 3.0.
Comment 16 Michael Monreal [:monreal] 2010-07-13 04:27:18 PDT
Personally I would prefer a "proper" solution (even if delayed to Fx.Next) to a short-lived hack which will need to be redone in one of the following releases anyway (see comments about glib/gtk 2.x being dead, basicly).

The question really is if Mozilla wants too be in a "linux release does not get the same love" position again.

Would be nice to know when we can expect a 4.0 release (realistically) and what the plan is beyond that. If you plan a 4.1 release "shortly" (~ 6 month) after 4.0 anyway, delaying the UI work on linux could end up being the best choice.
Comment 17 Dão Gottwald [:dao] 2010-07-13 04:44:37 PDT
(In reply to comment #14)
> Talking to Andreas Nilsson, we first concluded that a minimal approach would be
> fine for 4.0, e.g. having the ability to hide the menu while still keeping the
> window manager's window deco. This approach requires a menu button somewhere.

It also requires Alt to activate the menu bar. (You currently need Alt+[letter key].)

> We hacked together a prototype which draws a "Firefox" menu button in the tab
> bar, right in front of the first tab (similar to what you get on WinXP right
> now and what the latest Opera does).

Note that what we do for XP is a hack and intended to go away ASAP.
Comment 18 Michael Monreal [:monreal] 2010-07-13 05:15:26 PDT
>> Note that what we do for XP is a hack and 
>> intended to go away ASAP.

Yes, this was a misunderstanding at first and the reason why I was in favor of a similar solution for 4.0 on Linux, too (because it is so easy to implement). As this is not final on windows however, I now don't see a reason to go for a similar-yet-different concept which has some serious issues (less space for tabs etc) on Linux.
Comment 19 Andreas Nilsson (:andreasn) 2010-07-13 23:01:06 PDT
(In reply to comment #18)
> I now don't see a reason to go for a
> similar-yet-different concept which has some serious issues (less space for
> tabs etc) on Linux.

In a similar way one can argue that you'll get less space for the Actual Website Content with a traditional menu. Screens are wider than tall.
Comment 20 Michael Monreal [:monreal] 2010-07-14 01:43:28 PDT
Sure, we discussed this and I agree (though, I personally still use 4:3 screens where possible for some reason...) but is it really worth changing at this point and then changing again for 4.1 for example?
Comment 21 Alex Faaborg [:faaborg] (Firefox UX) 2010-07-14 12:58:32 PDT
>The question really is if Mozilla wants too be in a "linux release does not get
>the same love" position again.

Would giving users the option of placing a Firefox button in the tabstrip (directly below where it appears on windows) be enough to deflect this perception?

Overall I think it makes the most sense to default to a menu bar on Linux, since this is the expected behavior and interactively consistent with pretty much all other applications on that platform.  The only big downside is the increased UI footprint, and the perception that Firefox 4 isn't "new" enough.

Nonetheless, setting the Firefox button to be the default (regardless of placement in the tab strip or title bar) feels like we would be illogically bringing Windows Vista and 7 style UI to Linux.

Of course the big caveat here is that most people on Linux get Firefox through a distro, so whatever we choose to be the default interface isn't necessarily the same default that the distribution would choose, etc.
Comment 22 Colby Russell :crussell (no longer Mozilla-ing) 2010-07-14 13:07:09 PDT
(In reply to comment #21)
> Would giving users the option of placing a Firefox button in the tabstrip
> (directly below where it appears on windows) be enough to deflect this
> perception?

Just pointing out that the reason this didn't happen was because of a deficiency of WM APIs would, I think, go far.

> Overall I think it makes the most sense to default to a menu bar on Linux,
> since this is the expected behavior and interactively consistent with pretty
> much all other applications on that platform.  The only big downside is the
> increased UI footprint, and the perception that Firefox 4 isn't "new" enough.
> 
> Nonetheless, setting the Firefox button to be the default (regardless of
> placement in the tab strip or title bar) feels like we would be illogically
> bringing Windows Vista and 7 style UI to Linux.

Yes on this. The "unified cross-platform identity" seemed like a non-issue from the start, to be honest. The consistency provided by leaving the menubar intact has greater, further-reaching benefits than whatever niche subset of users the unified identity was intended to serve...
Comment 23 Alex Faaborg [:faaborg] (Firefox UX) 2010-07-14 13:19:25 PDT
>The consistency provided by leaving the menubar intact
>has greater, further-reaching benefits than whatever niche subset of users the
>unified identity was intended to serve...

also, if you consider that XP, and OS X will both still use the menu bar, overall there will likely be more Firefox users with a traditional menu bar interface then there will be users with a Firefox button.

But if user's want to opt in to having the Firefox button, because they saw a Windows 7 screenshot in the press and liked it, or want to have the same UI across multiple different platforms that they use throughout the day, they should certainly have that option.
Comment 24 Peter Henkel [:Terepin] 2010-07-14 13:23:55 PDT
(In reply to comment #23)
> >The consistency provided by leaving the menubar intact
> >has greater, further-reaching benefits than whatever niche subset of users the
> >unified identity was intended to serve...
> 
> also, if you consider that XP, and OS X will both still use the menu bar,
> overall there will likely be more Firefox users with a traditional menu bar
> interface then there will be users with a Firefox button.

Mac is using menu bar in different way. FB in Mac would be useless.
Comment 25 Alex Faaborg [:faaborg] (Firefox UX) 2010-07-14 13:30:09 PDT
I agree, although I would imagine that some people might still turn it on.  (especially people who are trying to access a global menu on a 30" screen)
Comment 26 Michael Monreal [:monreal] 2010-07-14 14:14:06 PDT
>> Would giving users the option of placing a Firefox button in 
>> the tabstrip (directly below where it appears on windows) be 
>> enough to deflect this perception?

Really hard to predict... It doesn't really save as much space (esp. in fullscreen I guess) and just hiding the menu bar is already possible in 3.6 (hide menubar extension, which is what I use atm).

>> Overall I think it makes the most sense to default to a menu 
>> bar on Linux, since this is the expected behavior

Generally this is true - but I have not seen any complains about a missing menu on Chrome/Linux for example (on the contrary... people enjoy this "non standart" UI a lot). Also, if you look at the latest mockups for the new file manager in GNOME3, you will also not find a menu... so the "expectations" may soon change on Linux. Lastly, the menu heatmaps shown at the summit didn't look very "red" at all :)

>> and the perception that Firefox 4 isn't "new" enough

You still plan to implement the new toolbar, awesomebar and tab styles on Linux, right? Those would give a totally "new" perception (which some will not like but I think most users will like)

As for this issue... a minimalistic approach would be to include the "show menu" command (currently ifdef'ed out on linux) and allow extensions to open the menu that opens from the Firefox button (this is currently not possible I think)
Comment 27 Alex Faaborg [:faaborg] (Firefox UX) 2010-07-15 17:49:04 PDT
>You still plan to implement the new toolbar, awesomebar and tab styles on
>Linux, right? Those would give a totally "new" perception

yep, also app tabs and the home tab.  Structurally though the menu bar is rather large, so it might make the application on the whole feel like it wasn't significantly updated, just in terms of pure pixel count.
Comment 28 Michael Monreal [:monreal] 2010-07-29 09:28:19 PDT
Created attachment 461240 [details]
GNOME-Shell App Menu

News from GUADEC: GNOME 3.0 is now officially delayed by 6 month (to march 2010). This also means GTK 3.0 will not ship in a month as planned before. Currently plan is to add some polish work and then release around Xmas.

Another thing I wanted to show is GNOME-Shell's new app button which is basicly a place where apps can add some menu items for the active app. The mockup even shows Firefox for whatever reason :)

To populate this app button, the new GtkApplication API from GTK 3 needs to be used which is now also being considered for a backport to GTK 2.22. If it turns out to be not a lot of work, maybe this would be worth to support conditionally?
Comment 29 Peter Henkel [:Terepin] 2010-07-29 09:37:26 PDT
As I said earlier, this will make into Firefox 4.x. Unfortunately.
Comment 30 Dão Gottwald [:dao] 2010-07-29 11:05:45 PDT
If the API becomes available soon, I think we'd very much want to use it.
Comment 31 Alex Faaborg [:faaborg] (Firefox UX) 2010-07-29 15:50:01 PDT
>If the API becomes available soon, I think we'd very much want to use it.

definitely, the Gnome-shell adding a standard app button control is really the ideal solution for us.
Comment 32 Mike Hommey [:glandium] 2010-09-05 23:57:30 PDT
Just trowing my 2¢ here, just to remind that on top of having a variety of window managers on Linux, a lot of those also don't expose window title bars *at all* (tiling window managers, for instance). Which means in any case, Firefox should support a setup with a Firefox button in the toolbar or somewhere else, at least as a fallback on those window managers.
Comment 33 Dão Gottwald [:dao] 2010-12-17 05:48:48 PST
See also bug 619899.
Comment 34 Ed Morley [:emorley] 2011-03-23 08:49:23 PDT
*** Bug 644160 has been marked as a duplicate of this bug. ***
Comment 35 Anil 2011-04-11 16:56:01 PDT
Hi

I am currently using the following workaround,
http://ubuntuforums.org/showpost.php?p=10608565&postcount=296

It would be nice if someone from ff dev team comeup with an action plan to have tabs on the title bar in a nice way, the ff way.

Thanks.
Comment 36 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-11-15 16:02:51 PST
*** Bug 702817 has been marked as a duplicate of this bug. ***
Comment 37 Bill Gianopoulos [:WG9s] 2011-11-15 16:11:25 PST
Ah I thought there was a bug wondering why I didn't find it.

As a point of reference here.  It was my understanding we were waiting for the gtk version that had support for this.

It is my understanding that that was included in fedora 15.

Fedora 14 is EOL as of December 8, so it woudl seem that Linux distro's that don;t support this feature are no longer supported anyway, so it should be safe to begin work on this.
Comment 38 alexhultman 2011-12-27 06:02:52 PST
In GNOME 3.4 you can remove the title bar when an app is maximized. This way you can actually "draw in the title bar". You can also do the same thing in Unity, so you really don't need to draw in the actual title bar, just draw as normal in the actual window and let the window manager drop the title bar when maximized. Compatible with Unity, GNOME 3.4 and does not break anything in GNOME 2 (yet you probably need some additional fix here).
Comment 39 alexhultman 2011-12-27 06:28:15 PST
Created attachment 584425 [details]
No title bar when maximized. Opt-in feature of GNOME 3.4.

Will look better with gtk3 and some new icons but it's one solution for "drawing in the title bar".
Comment 40 Michael Monreal [:monreal] 2011-12-27 06:38:27 PST
I like it, but I don't really like the fact that we will have the Firefox button right below the Activities button. What is the status of application menus (on the right side of Activities) in GNOME 3.4?
Comment 41 alexhultman 2011-12-27 06:45:10 PST
(In reply to Michael Monreal [:monreal] from comment #40)
> I like it, but I don't really like the fact that we will have the Firefox
> button right below the Activities button. What is the status of application
> menus (on the right side of Activities) in GNOME 3.4?

https://live.gnome.org/ThreePointThree/Features/ApplicationMenu.

No maximized title bar + menus in the top bar is features of GNOME 3.4. That's what you mean right?
Comment 42 alexhultman 2011-12-27 07:08:56 PST
Notice that Chrome has no anti-aliased window corners and no drop shadow like any other native gtk2/3 app. It looks like **** really.
Comment 43 Bill Gianopoulos [:WG9s] 2011-12-27 07:23:09 PST
(In reply to alexhultman from comment #41)
> (In reply to Michael Monreal [:monreal] from comment #40)

> No maximized title bar + menus in the top bar is features of GNOME 3.4.
> That's what you mean right?

I think what he meant was can we get the Firefox dropdown menu next to the Activities menu populated with the Firefox button menu so that the Firefox button does not need to be displayed on the tabbar at all and the menu next to the Activities menu on the top bar has more choices than just quit.
Comment 44 alexhultman 2011-12-27 09:33:43 PST
(In reply to Bill Gianopoulos from comment #43)
> (In reply to alexhultman from comment #41)
> > (In reply to Michael Monreal [:monreal] from comment #40)
> 
> > No maximized title bar + menus in the top bar is features of GNOME 3.4.
> > That's what you mean right?
> 
> I think what he meant was can we get the Firefox dropdown menu next to the
> Activities menu populated with the Firefox button menu so that the Firefox
> button does not need to be displayed on the tabbar at all and the menu next
> to the Activities menu on the top bar has more choices than just quit.

Yes that's how I understood it. Look at the link I posted, or have a look at the GNOME Boxes mockup: https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-menu.png

3.4 lets apps have their menus drop down from the top Shell bar. 3.2 only displays the Quit entry. You could remake the Firefox menu into a Shell menu for 3.4 and remove the button in the tabs area. I think that would be very nice.
Comment 45 alexhultman 2011-12-27 09:38:33 PST
I think this bug depends on Bug 627699 - Port GTK2 to GTK3, if you want the 3.4 features.
Comment 46 Michael Monreal [:monreal] 2011-12-27 10:00:27 PST
(In reply to Bill Gianopoulos from comment #43)
> I think what he meant was can we get the Firefox dropdown menu next to the
> Activities menu populated with the Firefox button menu so that the Firefox
> button does not need to be displayed on the tabbar at all and the menu next
> to the Activities menu on the top bar has more choices than just quit.

Right. For now I was mainly wondering how that "Application menu" as they call it meant to be used. For some time, it was not meant to replace whole menu bars and only include some basic stuff like "New..." actions. This *seems* to have changed if recent mockups can be trusted.

But I don't think a dual layout, buttons or even sub menus are supported?


(In reply to alexhultman from comment #45)
> I think this bug depends on Bug 627699 - Port GTK2 to GTK3, if you want the
> 3.4 features.

Well, yes, I guess. At least GApplication is needed, which can be found in recent glib only.
Comment 47 alexhultman 2011-12-27 10:48:26 PST
Submenus are supported. I think you could implement a simplified version of the current Firefox menu in that Shell menu. Otherwise you just leave it be. Gtk3 + no title bar actually solves this bug because then you can draw whatever stuff you want since everything is client area.
Comment 48 alexhultman 2011-12-27 11:11:13 PST
Created attachment 584458 [details]
Shell menu
Comment 49 Karl Tomlinson (:karlt) 2011-12-27 14:20:36 PST
(In reply to alexhultman from comment #39)
> Will look better with gtk3 and some new icons but it's one solution for
> "drawing in the title bar".

(In reply to alexhultman from comment #47)
> Gtk3 + no title bar actually solves this bug because then you can draw
> whatever stuff you want since everything is client area.

What is the feature that GTK3 will provide here?  I'm guessing you are not referring to the client-side decorations of comment 14, because I assume no titlebar means no decorations.

If Gecko were using GTK to create menus, then I guess it would (one day with new enough GTK) benefit from GMenuModel automatically.  However, Gecko currently creates menu windows itself, using only GTK theme engines for drawing.
Comment 50 alexhultman 2011-12-27 14:57:00 PST
(In reply to Karl Tomlinson (:karlt) from comment #49)
> What is the feature that GTK3 will provide here?

Overview of Changes in GTK+ 3.3.6
=================================

* GtkWindow can now request that the window manager hide
  the titlebar when the window is maximized.

Comment 38

> I'm guessing you are not
> referring to the client-side decorations of comment 14, because I assume no
> titlebar means no decorations.

No, not custom like Chrome. The title bar only drops in maximized mode and you don't need to draw any custom decorations, just use the whole client area anyhow you want.

> If Gecko were using GTK to create menus, then I guess it would (one day with
> new enough GTK) benefit from GMenuModel automatically.  However, Gecko
> currently creates menu windows itself, using only GTK theme engines for
> drawing.

You can keep doing that. It's up to you. I'm just highlighting the Shell menu as an option.
Comment 51 Karl Tomlinson (:karlt) 2011-12-27 15:51:42 PST
(In reply to alexhultman from comment #50)
> Overview of Changes in GTK+ 3.3.6
> =================================
> 
> * GtkWindow can now request that the window manager hide
>   the titlebar when the window is maximized.

Thanks.  That code is in
http://git.gnome.org/browse/gtk+/commit/gdk/x11?id=4f8f8fe828dbb5b1a2e54a26a58149e437cd5820

It wouldn't be hard to set the _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED property even with the gtk2 port.

The designs at https://live.gnome.org/GnomeOS/Design/Whiteboards/WindowStates
don't have minimize or maximize/restore buttons even on non-maximized windows, so I wonder how multitasking is managed.

> I'm just highlighting the Shell menu as an option.

OK, thanks.  I haven't looked in the details but Bug 619899 discusses some work Chris Coulson did to support panel-based menus under Unity.
Comment 52 alexhultman 2011-12-27 16:52:31 PST
(In reply to Karl Tomlinson (:karlt) from comment #51)
> The designs at https://live.gnome.org/GnomeOS/Design/Whiteboards/WindowStates
> don't have minimize or maximize/restore buttons even on non-maximized
> windows, so I wonder how multitasking is managed.

Minimize & maximize buttons was dropped in GNOME 3.0. If it's possible to set that flag in gtk2 it should be done straight away i think. Firefox maximized on Linux will then look the same as Firefox maximized on Windows. The only difference will be Linux missing min/max/close buttons but that's how it's supposed to be. You manage windows in a different way in GNOME 3.
Comment 53 alexhultman 2011-12-27 17:07:06 PST
Created attachment 584512 [details]
Windows vs Linux theming, not maximized

When not maximized, Windows and Linux versions currently look the same except for the placement of the Firefox button.
Comment 54 William Lachance (:wlach) 2012-01-18 15:12:42 PST
As a datapoint/inspiration, here's an interesting blog post about what Epiphany (a GNOME-based web browser) is doing with GNOME Shell. Looks quite slick IMO.

http://blogs.gnome.org/xan/2012/01/17/epiphany-marches-on/
http://blogs.gnome.org/xan/files/2012/01/ephy-complete.png
Comment 55 Chris Coulson 2012-01-18 15:32:23 PST
(In reply to Karl Tomlinson (:karlt) from comment #49)

> 
> If Gecko were using GTK to create menus, then I guess it would (one day with
> new enough GTK) benefit from GMenuModel automatically.  However, Gecko
> currently creates menu windows itself, using only GTK theme engines for
> drawing.

I think the intention is that applications will actually use GMenuModel directly rather than GTK menus. The menu can then either be visualized in the window by GTK, or displayed by the shell (eg, the panel menubar in Unity, or for the application menu in GNOME, although these are 2 different types of menus really).

Once GMenuModel has matured a little, I will add some patches to bug 619899 to create a menu structure using it. However, there is currently no way to tell if a menu is open yet with GMenu, and I talked to Ryan Lortie just last week about this. I'm quite keen to stop maintaining https://launchpad.net/globalmenu-extension soon :-)
Comment 56 alexhultman 2012-01-24 00:56:15 PST
(In reply to William Lachance (:wlach) from comment #54)
> As a datapoint/inspiration, here's an interesting blog post about what
> Epiphany (a GNOME-based web browser) is doing with GNOME Shell. Looks quite
> slick IMO.
> 
> http://blogs.gnome.org/xan/2012/01/17/epiphany-marches-on/
> http://blogs.gnome.org/xan/files/2012/01/ephy-complete.png

I'm running it now and it looks awesome. It's important to notice that the title bar goes away when you maximize it just like I wrote about before. None of those images show that. Almonst the entire screen is content. The menu drops down from the top bar and it works great.
Comment 57 alexhultman 2012-02-07 21:07:20 PST
One explicit feature of Wayland is to allow the toolkit (GTK3) to decorate it's own windows. It's not about drawing the whole thing custom, I guess GTK3 will draw the default Mutter decorations but you will be able to draw like a layer on top.

That's in the future. For now dropping the title bar will be enough. You should probably start drawing custom tabs/buttons/icons though. Windows version doesn't use Win32 tabs :P
Comment 58 Jo Hermans 2012-02-22 03:01:52 PST
*** Bug 729460 has been marked as a duplicate of this bug. ***
Comment 59 A, T 2013-03-20 17:39:51 PDT
Is this bug dead? I thought this would garner more attention after OSX will be getting their tabs in titlebar done very soon, https://bugzilla.mozilla.org/show_bug.cgi?id=625989.

I might be blind but I didn't see this bug under the [Australis]Linux metabug, do you have no plans of getting rid of that ugly and theme inconsistent title bar?
Comment 60 Mike Conley (:mconley) 2013-03-27 07:13:52 PDT
I believe bug 627699 needs to be resolved before this can be attempted.
Comment 61 gatlibs 2013-10-02 09:57:31 PDT
Would Firefox be able to use Gnome 3.10's new Header Bar for this? Anything that is GTK3 will be usable on Wayland as well.
Comment 62 donrhummy 2013-10-30 07:32:52 PDT
Can someone explain why Mozilla doesn't just get rid of the title bar and make your own (that would be easier to control the layout/ui)?
Comment 63 alexhultman 2013-10-30 08:01:18 PDT
You don't want to remove the system title bar, that almost always introduces jagged edges and non-system look and feel. GtkHeaderBar in GTK 3.10 is the new feature that lets you draw in the (native) title bar: https://developer.gnome.org/gtk3/3.10/GtkHeaderBar.html

Works in X and Wayland.
Comment 67 Antoine.Saroufim 2013-11-22 13:51:13 PST
A hearderbar should definitely be added as an option. Headerbars aren't just something related to GNOME. Other desktop environments such as Pantheon are looking forward to adopting them. Some apps have already been built from the ground up to use headerbars such as budgie, a media player. Firefox, without Australis, doesn't look great with Adwaita and isn't the least bit integrated with GNOME. No AppMenu, no dbus notifications, and it has a titlebar when using the full screen. The first step to mend that is by adding a headerbar, at least as an option, to make Firefox look more coherent.
Comment 68 Matthew N. [:MattN] (PM me if requests are blocking you) 2014-01-22 05:27:13 PST
*** Bug 958811 has been marked as a duplicate of this bug. ***
Comment 69 Karl Tomlinson (:karlt) 2014-06-30 14:30:22 PDT
_NET_WM_PERFORM_BUTTON_ACTION will likely be helpful in resolving some of the window manager integration issues here.
https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html
Comment 70 Martin Stránský 2014-12-11 02:46:01 PST
*** Bug 1109648 has been marked as a duplicate of this bug. ***
Comment 71 Florian Müllner 2014-12-11 06:07:09 PST
I'm afraid that client-side decorations are still very much GNOME specific at this point - it's not that they couldn't integrate with other environments, but as far as I know, that's not the case at the moment. So for now I would consider only implementing client-side decorations when running under GNOME, based on something like the GtkSettings:gtk-shell-shows-app-menu property.

That said, this is roughly what GTK does:
 - use MWM hints to disable the WM titlebar (either by requesting border-only decorations, or
   by disabling decorations altogether, depending on whether the screen is composited and has
   an rgba visual)
 - add "WM" buttons to its custom titlebar according to the GtkSettings:gtk-decoration-layout setting
   (on X11, this is backed by an XSetting, though I don't think it is set by any environment other
   than GNOME - the default is decidedly un-gnomey though (read: includes minimize and maximize buttons))
 - emit the _GTK_SHOW_WINDOW_MENU client message on right-click if supported by the WM, otherwise
   display a very basic fallback menu (just "close")(*)
 - if WM decorations are disabled completely, handle stuff like border resize, window shadows, invisible borders, ...

I hope this answers at least some of the questions that came up in this thread - I'll be happy to (try to) answer any follow-up questions as necessary if it helps getting us a better firefox :-)


(*) something like the _NET_WM_PERFORM_BUTTON_ACTION mentioned in comment #69 would allow to not hard-code right-click here, but support for that hasn't landed, see the follow-up mail; if it would help you push things forward though, we could easily implement something along those lines.
Comment 72 :Gijs Kruitbosch 2015-01-07 02:37:37 PST
*** Bug 1118521 has been marked as a duplicate of this bug. ***
Comment 73 Terrell Kelley 2015-01-07 10:10:26 PST
Created attachment 8545331 [details]
Top is current, bottom is my customized version with Hide Caption Title Bar Plus

Since my bug is a duplicate, I'll repeat the info I provided there.

There is already an addon out there that does a lot of the work, called "Hide Caption Title Bar Plus" (https://addons.mozilla.org/en-US/firefox/addon/hide-caption-titlebar-plus-sma/). The main problem is just the lack of a title-bar theme color, which I accomplish by using a different theme than the default. I will attach a screenshot of the results of using this addon. (The theme I chose can be seen in one of the tabs.)
Comment 74 Марко М. Костић (Marko M. Kostić) [:Kostic] 2015-10-25 08:41:52 PDT
Any progress on this bug? Is the transition to GTK3 still a blocker for this bug?
Comment 75 YF (Yang) 2015-12-22 03:25:48 PST
*** Bug 1234433 has been marked as a duplicate of this bug. ***
Comment 76 alex_mayorga 2016-01-14 12:34:02 PST
¡Hola Mike!

Is this bug why the button to hide the "Title Bar" is missing at https://support.cdn.mozilla.net/media/uploads/images/2016-01-14-10-53-50-77dd32.png ?

¡Gracias!
Comment 77 Mike Conley (:mconley) 2016-01-15 10:24:42 PST
Yes, that's correct. Gecko now builds against GTK3, which (I believe) gives us the ability to draw into the window titlebar area. The support for doing that hasn't been built into the Gecko GTK backend, however. Once that's done, we could draw the tabs in the titlebar and expose that button.
Comment 78 :Gijs Kruitbosch 2016-03-30 05:02:05 PDT
*** Bug 1258969 has been marked as a duplicate of this bug. ***
Comment 79 Dale Harvey (:daleharvey) 2016-05-04 10:50:03 PDT
Mike asked me to take a look at this
Comment 80 Dale Harvey (:daleharvey) 2016-05-04 11:32:46 PDT
Hey Mike, getting a linux build ready now, a little pointer to where in the code to start would really help, thanks
Comment 81 Mike Conley (:mconley) 2016-05-04 12:09:53 PDT
(In reply to Dale Harvey (:daleharvey) from comment #80)
> Hey Mike, getting a linux build ready now, a little pointer to where in the
> code to start would really help, thanks

Hey Dale,

Sure thing. Here's the Windows version of this bug for context: bug 513162
And the OS X version of this bug: bug 625989

I think you'll likely want to follow the OS X example in terms of depth of implementation (I don't think you need to care about painting on the left, right, or bottom margins - just the top one). This will involve implementing SetNonClientMargins in the GTK nsWindow implementation at https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsWindow.cpp.

Note that this sort of titlebar drawing is only supported in GTK 3, so if we've got any ifdefs for GTK3 stuff, this should probably fall into it.

Here's the function I think we're going to need to talk to: gtk_window_set_decorated

https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-set-decorated

Unfortunately, there is this passage: " Depending on the system, this function may not have any effect when called on a window that is already visible, so you should call it before calling gtk_widget_show().", so we'll need to test that scenario, and come up with a workaround (maybe hiding and re-showing the browser?) if it turns out that set_decorated has no effect on a visible window.

Here's the Chromium browser removing the titlebar: https://code.google.com/p/chromium/codesearch#chromium/src/remoting/host/disconnect_window_linux.cc&q=gtk_window_set_decorated&sq=package:chromium&type=cs&l=109

Probably best to use the latest Ubuntu LTS release as a test bed.

I'll note that my GTK chops are likely a bit rusty, and that karlt (New Zealand, I believe), is far and away more familiar with its intricacies than I am (dholbert might be a good resource too).

Does that give you something to work with?
Comment 82 Mike Conley (:mconley) 2016-05-04 12:11:24 PDT
One thing of interest is that gtk_window_set_decorated has been around longer than GTK3 has. I recall somebody mentioning us not being able to draw in the titlebar until GTK3 rolled around though, so it might be worth talking to somebody (karlt? dholbert?) to figure out why that was. It'd be kind of a tragedy if it was erroneous hearsay. :/
Comment 83 Martin Stránský 2016-05-04 12:20:16 PDT
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #82)
> One thing of interest is that gtk_window_set_decorated has been around
> longer than GTK3 has. I recall somebody mentioning us not being able to draw
> in the titlebar until GTK3 rolled around though, so it might be worth
> talking to somebody (karlt? dholbert?) to figure out why that was. It'd be
> kind of a tragedy if it was erroneous hearsay. :/

AFAIK GTK3 apps which does not draw titlebar (gedit, evince) use gtk_window_set_decorated() to hide system decorations which is reliable in various DE. 

Gtk3 introduces a new widget here - GtkHeaderBar - which can act as the system titlebar (https://developer.gnome.org/gtk3/stable/GtkHeaderBar.html) but I don't think we want to use that approach.
Comment 84 Martin Stránský 2016-05-04 12:24:15 PDT
btw. You may mean new Gtk3 function gtk_window_set_hide_titlebar_when_maximized(). It looks promising but from my testing it works in gnome-shell only. Other DE (MATE, KDE, XFCE, Cinamon) ignores that and shows menubar on maximized windows.
Comment 85 Marco Castelluccio [:marco] 2016-05-04 14:11:43 PDT
See also bug 900740, there was a WIP patch I was working on and some useful comments by karlt.
Comment 86 Daniel 2016-05-04 21:42:26 PDT
(In reply to Martin Stránský from comment #83)
> Gtk3 introduces a new widget here - GtkHeaderBar - which can act as the
> system titlebar (https://developer.gnome.org/gtk3/stable/GtkHeaderBar.html)
> but I don't think we want to use that approach.
What's wrong with GtkHeaderBar?
Comment 87 Martin Stránský 2016-05-05 02:05:44 PDT
(In reply to Daniel from comment #86)
> What's wrong with GtkHeaderBar?

IMHO GtkHeaderBar usage would need extra Gtk specific approach which couldn't be shared with Window/Mac.
Comment 88 Dale Harvey (:daleharvey) 2016-05-05 04:13:48 PDT
Yup thats plenty to get started with, thanks
Comment 89 Terrell Kelley 2016-05-05 06:29:53 PDT
What I understood is that they were waiting on GTK3 more to not waste code, since GTK3 was coming. Not because it was impossible before. 

And don't forget about multi-row tabs and Tab Mix Plus when doing this. I don't use it much anymore, but a lot of people do. 

And, of course, keep the ability that the addon I mentioned earlier uses--the ability for an addon to turn off the titlebar entirely and replace it. That's what Hide Caption Title Bar Plus, does, and I love the shorter tabs option it provides.
Comment 90 Florian Müllner 2016-05-05 07:34:40 PDT
(In reply to Martin Stránský from comment #83)
> AFAIK GTK3 apps which does not draw titlebar (gedit, evince) use
> gtk_window_set_decorated() to hide system decorations which is reliable in
> various DE.

They generally call gtk_window_set_titlebar() to set a custom titlebar widget (a GtkHeaderBar in most cases), but I don't think anything besides the call to gdk_window_set_decorations()[0] is relevant for Firefox.

[0] https://git.gnome.org/browse/gtk+/tree/gtk/gtkwindow.c#n7299


> Gtk3 introduces a new widget here - GtkHeaderBar - which can act as the
> system titlebar (https://developer.gnome.org/gtk3/stable/GtkHeaderBar.html)
> but I don't think we want to use that approach.

If some inspiration is wanted for drawing a titlebar that imitates GTK+'s headerbar-based decorations, here's a link to the relevant code in mutter:
https://git.gnome.org/browse/mutter/tree/src/ui/theme.c


(In reply to Martin Stránský from comment #84)
> btw. You may mean new Gtk3 function
> gtk_window_set_hide_titlebar_when_maximized(). It looks promising but from
> my testing it works in gnome-shell only.

Right, I don't think anyone else implemented that. It's only relevant if you don't use a custom titlebar anyway, so it has mostly been superseded in GNOME as well.
Comment 91 Daniel 2016-05-06 11:34:35 PDT
(In reply to Martin Stránský from comment #87)
> IMHO GtkHeaderBar usage would need extra Gtk specific approach which
> couldn't be shared with Window/Mac.
Does Win/Mac share anything here? So why don't we have tabs in titlebar in Linux? I guessed it always was platform-specific thing only. Moreover, GtkHeaderBar has no limitations, you can put pretty everything there, thus there are no reasons to reject this approach without a careful investigation.
Comment 92 Dale Harvey (:daleharvey) 2016-05-15 16:27:25 PDT
Btw I have noticed that on latest m-c running in Ubuntu LTS (16.04) there is no file menu at all, on fx 46 it is as expected in the top bar when hovered over, but not on my current build, anyone know whats up with that?

gtk_window_set_decorated works fine to remove the titlebar but leaves fairly ugly square corners, chrome looks like its drawing everything above that itself, the rounded corners and the decorations, its a little jarring. Seeing if I can get this to draw native decorations as we do on mac.

Not sure about how to get the rounded corners + gradient back on the title however, will GtkHeaderBar help with that? trying to find examples of applications as opposed to themes that do this but not coming up with many as yet
Comment 93 Mike Conley (:mconley) 2016-05-15 17:19:16 PDT
If I remember correctly, the Canonical builds of Firefox come included with an extension that does the work of making the XUL menubar work with the global menu in the Ubuntu interface (using js-ctypes, if I remember correctly).

Your local builds won't have this extension. I think, however, that the menu _might_ be collapsed by default on Ubuntu. Try right-clicking next to the tab strip and seeing if you can re-enable it.
Comment 94 Michael Catanzaro 2016-05-15 18:38:09 PDT
I *really* doubt that you'd be able to use GtkHeaderBar in Firefox. My understanding is that Firefox uses just the unstable foreign drawing API rather than an actual GtkWidget hierarchy. Accordingly, you should pay attention to Florian's comment #90, which shows you how to imitate GtkHeaderBar using the foreign drawing API.

Note that testing with Ubuntu 16.04 is a really bad idea, since that distro has obsolete GTK+ 3.18. All foreign drawing code written for older versions of GTK+ needs to be completely rewritten for GTK+ 3.20, unfortunately.
Comment 95 Martin Stránský 2016-05-16 04:54:58 PDT
(In reply to Michael Catanzaro from comment #94)
> Note that testing with Ubuntu 16.04 is a really bad idea, since that distro
> has obsolete GTK+ 3.18. All foreign drawing code written for older versions
> of GTK+ needs to be completely rewritten for GTK+ 3.20, unfortunately.

That's not completely correct. The moz_gtk_widget_paint() from gtk3drawing.cpp provides version independent way for rendering the Gtk3 widgets. It can be also extended for recently unsupported ones like the GtkHeaderBar.
Comment 96 Dale Harvey (:daleharvey) 2016-05-18 08:36:03 PDT
Meant to clear the needinfo before
Comment 97 Kestrel 2016-05-26 04:53:24 PDT
(In reply to Mike Conley (:mconley) - (needinfo me!) from comment #93)
> If I remember correctly, the Canonical builds of Firefox come included with
> an extension that does the work of making the XUL menubar work with the
> global menu in the Ubuntu interface (using js-ctypes, if I remember
> correctly).

Global menus are done with a build patch now (debian/patches/unity-menubar.patch) and can be toggled in about:config with ui.use_unity_menubar.
Comment 98 Dale Harvey (:daleharvey) 2016-05-27 01:11:14 PDT
Ok so after some fairly basic investigation, drawing native decorations in our own layout does not seem possible, |gtk_button_new_from_name("window-close", .. | gives us the non standard decoration, so if we |gtk_window_set_decorated(mShell, false)| and draw our own title bar, we will have to draw our own rounded corners + gradient + decorations (close button etc). From early experiments it seems like this is going to be very hard to make look good / natural, chrome does this 'ok', but not perfect by any stretch and I cant find any other examples that do it well.

HeaderBar gives us very close to the layout we want, it looks natural and is all aliased, it looks like it might take up a little extra space (plus there is a visual spacer it seems like we cant get rid of), It seems like the way to go. 

I am having a hard time figuring out how to put it in there so any guidance on that front would be really helpful, thanks
Comment 99 Martin Stránský 2016-05-27 01:26:29 PDT
(In reply to Dale Harvey (:daleharvey) from comment #98)
> I am having a hard time figuring out how to put it in there so any guidance
> on that front would be really helpful, thanks

If you want to use an existing GTK rendering infrastructure you need to add a new widget to:

http://mxr.mozilla.org/mozilla-central/source/widget/gtk/gtkdrawing.h

and implement rendering at:

http://mxr.mozilla.org/mozilla-central/source/widget/gtk/gtk3drawing.cpp

You also need to implement mapping from Mozilla widgets to Gtk widgets in:

http://mxr.mozilla.org/mozilla-central/source/widget/gtk/nsNativeThemeGTK.cpp#190

where NS_THEME_* widgets are translated to MOZ_GTK_* widgets. When it's done you can draw it as a standard mozilla XUL/HTML element AFAIK.
Comment 100 Dale Harvey (:daleharvey) 2016-05-27 01:56:40 PDT
Martin, thanks a lot that is really useful. You doubted that using GtkHeaderBar is the way to go, what do you think is the best way to have this implemented?
Comment 101 Martin Stránský 2016-05-27 02:21:44 PDT
(In reply to Dale Harvey (:daleharvey) from comment #100)
> Martin, thanks a lot that is really useful. You doubted that using
> GtkHeaderBar is the way to go, what do you think is the best way to have
> this implemented?

I see that Windows use NS_THEME_WINDOW_TITLEBAR Mozilla theme here. So I'd implement similar one for Linux which may map to a some Gtk widget (or not - it depends). But I have no idea how NS_THEME_WINDOW_TITLEBAR actually works, if that's just a background/container for other widgets.

The whole titlebar rendering implementation for Windows seems to be in Bug 513162. I recommend to ask windows folks, Bug 574454 adds the NS_THEME_WINDOW_TITLEBAR element.
Comment 102 Florian Müllner 2016-05-27 02:58:18 PDT
(In reply to Martin Stránský from comment #101)
> So I'd implement similar one for Linux which may map to a some Gtk widget

GtkHeaderbar. To imitate a headerbar, the GtkStyleContext should have GTK_TYPE_HEADER_BAR in the widget path, use an object name of "headerbar" and have the style classes "titlebar" and "horizontal" (and if you don't want to put any custom controls in the titlebar, "default-decoration" as well). Using that context with gtk_render_background() and gtk_render_frame() should get you close to a native look. Unfortunately, themes may use constructs like ".titlebar button" to style buttons in titlebars differently from "normal" buttons - to get those correctly, your style contexts need to reflect the hierarchy they would have if actual GtkWidgets were used. It's possible to do that with gtk_style_context_set_parent() (and building up the correct widget path), but a quick glance at the code linked by Martin suggests that this would require fairly big changes.
Comment 103 Dale Harvey (:daleharvey) 2016-05-30 07:40:08 PDT
So hoping to get back to this, however it is fairly heavy for a first patch to desktop front end so going to pick up a few other intro bugs then get back to this, thanks a lot for the tips.
Comment 104 Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-06-10 17:32:03 PDT
I'm going to give this a shot, as it's necessary for blitting to the window directly OMT using Wayland (unless we use wl_subsurfaces, which GDK doesn't really expose yet for drawing).

I plan on leveraging some of the existing CSD infrastructure, drawing natively using NS_THEME_WINDOW_TITLEBAR and the like, rather than assigning our GtkWindow a custom titlebar widget. GtkHeaderBar will be used to provide styling for 3.10 and above- however, I think it's useful to have sane fallback decorations for other GTK versions rather than killing CSD entirely.
Comment 105 Karl Tomlinson (:karlt) 2016-06-12 20:45:49 PDT
(In reply to Andrew Comminos [:acomminos] from comment #104)
> I'm going to give this a shot, as it's necessary for blitting to the window
> directly OMT using Wayland (unless we use wl_subsurfaces, which GDK doesn't
> really expose yet for drawing).
> 
> I plan on leveraging some of the existing CSD infrastructure, drawing
> natively using NS_THEME_WINDOW_TITLEBAR and the like, rather than assigning
> our GtkWindow a custom titlebar widget. GtkHeaderBar will be used to provide
> styling for 3.10 and above- however, I think it's useful to have sane
> fallback decorations for other GTK versions rather than killing CSD entirely.

I doubt earlier versions will have sane behavior with CSD.
https://bugzilla.gnome.org/show_bug.cgi?id=756618 is some evidence of that in 3.18 even.

The Wayland ABI has been unstable up to 3.20 at least, so Wayland support is not considered ready on older systems at least.
http://abi-laboratory.pro/tracker/compat_report/gtk+/3.18.9/3.20.0/a91f6/abi_compat_report.html#Removed

Having sane behavior with server-side decorations is much more important than CSD on older systems.
Comment 106 Neil Deakin 2016-06-15 11:42:00 PDT
*** Bug 1279960 has been marked as a duplicate of this bug. ***
Comment 107 Марко М. Костић (Marko M. Kostić) [:Kostic] 2016-06-24 01:26:41 PDT
Is there perhaps a bountysource for this bug? This bug literally is the only major thing that irks me with Firefox on Linux. If it gets resolved I would be so happy. Is it allowed to create a bountysource for it? If not, is there any other way approved by Mozilla to directly financially support the developer working on it?
Comment 108 :Gijs Kruitbosch 2016-08-18 08:28:56 PDT
*** Bug 1296314 has been marked as a duplicate of this bug. ***
Comment 109 troy.heron 2016-08-18 15:02:32 PDT
I agree with Marko, this is the only thing stopping me from changing back to Firefox from Chrome.

Note You need to log in before you can comment on or make changes to this bug.