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.

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.

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.

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

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.

(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.

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

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.

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

It will be: 1. Eye candy 2. Space saving if upper edge of window blends with gnome-panel, when tabs are drawed in titlebar.

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).

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.

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

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/

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.

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.

(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.

>> 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.

(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.

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?

>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.

(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...

>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.

(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.

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)

>> 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)

>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.

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?

As I said earlier, this will make into Firefox 4.x. Unfortunately.

If the API becomes available soon, I think we'd very much want to use it.

>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.

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.

See also bug 619899.

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.

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.

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).

Will look better with gtk3 and some new icons but it's one solution for "drawing in the title bar".

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?

(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?

Notice that Chrome has no anti-aliased window corners and no drop shadow like any other native gtk2/3 app. It looks like **** really.

(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.

(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.

I think this bug depends on Bug 627699 - Port GTK2 to GTK3, if you want the 3.4 features.

(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.

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.

(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.

(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.

(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.

(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.

When not maximized, Windows and Linux versions currently look the same except for the placement of the Firefox button.

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

(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 :-)

(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.

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

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?

I believe bug 627699 needs to be resolved before this can be attempted.

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.

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)?

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.

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.

_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

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.

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.)

Any progress on this bug? Is the transition to GTK3 still a blocker for this bug?

¡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!

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.

Mike asked me to take a look at this

Hey Mike, getting a linux build ready now, a little pointer to where in the code to start would really help, thanks

(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?

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. :/

(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.

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.

See also bug 900740, there was a WIP patch I was working on and some useful comments by karlt.

(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?

(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.

Yup thats plenty to get started with, thanks

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.

(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.

(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.

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

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.

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.

(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.

Meant to clear the needinfo before

(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.

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

(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.

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?

(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.

(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.

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.

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.

(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.

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?

I agree with Marko, this is the only thing stopping me from changing back to Firefox from Chrome.

[Tracking Requested - why for this release]:(In reply to Andrew Comminos [:acomminos] (back to classes, will be slow) 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. This should blocker this bug 1325171 & bug 1349423

(In reply to Mefoster from comment #111) > This should blocker this bug 1325171 & bug 1349423 No, it's out of scope.

Yes, cross plattform Photon work is more important than this, but: With deprecation of XUL addons in Firefox 57, this solution with AMO:"Hide Caption Titlebar Plus" wouldn't work anymore: https://github.com/Javier-DarthPalpatine/firefox-hide-caption-titlebar-plus/issues/315#issuecomment-254288490 (Firefox on the left (ignore red arrows), Chromium on the right) According to https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/ this bug would be good for Firefox 58, when we are over the hill. It shouldn't be that hard then, as the mentioned xul addon can provide the desired behavior.

Yes. If I lose the ability to put the tabs in the title bar, that's a blocker for me to upgrade. Why upgrade to an inferior browser experience? Though I'd think it should be targeted for Firefox 57, since that's when legacy addons break. Also, just to be clear, HCTBP is a Restartless/SDK addon, not an XUL-based addon.

Indeed, this issue is quite important. > According to https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/ this bug would be good for Firefox 58, when we are over the hill. I just don't understand this. IMHO it should be fixed in Firefox 57 at the latest, so when we cannot use legacy add-ons, which provide this functionality, it should be built-in into Firefox. Or, better, of course, would be to have it even earlier.

(In reply to rugk from comment #116) > Indeed, this issue is quite important. > I agree. As a workaround, you can remove window decorations using the following xprop command in your startup script for example: xprop -id $WID -f _MOTIF_WM_HINTS 32c -set _MOTIF_WM_HINTS "0x2, 0x0, 0x0, 0x0, 0x0" On GNOME, you can still maximize and window-ify by dragging the tab bar to the top and close using the shell or build-in menu items. You will lose window buttons, though (not too bad considering there is only close by default on GNOME anyway). Maybe minimize/maximize/close buttons could be implemented as custom UI elements to be used in customize mode?

Thx for the workaround. But how can I get the $WID? (I assume this is the "window ID" of Firefox)

(In reply to rugk from comment #119) > Thx for the workaround. But how can I get the $WID? (I assume this is the > "window ID" of Firefox) Try running the command line tool xwininfo from Xorg X11 utils.

The desired effect is already available in full-screen mode. What's so hard enabling it in normal mode, by adding "use system bars and borders" option like they did years ago in chromium?

Full-screen mode doesn't implement dragging on the edges for example.

(In reply to Jan Niklas Hasse from comment #123) > Full-screen mode doesn't implement dragging on the edges for example. But at least it could fit in maximized view.

The work is done at Bug 1283299 so closing this one as a duplicate.