New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 55 users

Issue metadata

Status: Fixed
Closed: Nov 2017
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

issue 753067

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 21438: In Linux, respect the system setting for placement of close/minimize/maximize buttons

Reported by, Sep 10 2009

Issue description

Chrome Version       : Using daily builds

In Linux you're able to choose the side where to have the close minimize
and maximize buttons chromium should respect that, when you set the
decorator buttons order in metacity chromium should respect that and adjust
it self, I like to have the close, maximize and minimize buttons on the
left of the window, like in osx, and in my desktop all windows work like
that except for the chromium window, and that looks and feels awkward...

Comment 1 by, May 16 2011

Labels: -OS-All -Area-Misc OS-Linux Area-UI Feature-Browser

Comment 2 by, May 16 2011

We listen to the metacity gconf key. If you aren't seeing the location live change when you change the button configuration key, could you give some details on your desktop environment?

Comment 3 by, May 19 2011

Status: Untriaged
Comments from developers ?

Comment 4 by, May 19 2011

@3 I already did.

Evan, I remember vaguely you mentioned that on one of your coworker's machines, this wasn't working as expected.

Comment 5 by, May 19 2011

Labels: Action-FeedbackNeeded
The close button is on the left of my window because I configured my system that way.  If this doesn't work you'll need to provide more information.

Comment 6 by, May 19 2011

The close button is on the left of my window because I configured my system that way.  If this doesn't work you'll need to provide more information.

Comment 7 by, Jun 1 2012


Comment 8 by, Jun 11 2012

(Un-ccing myself from bugs.)

Comment 9 by, Mar 9 2013

Project Member
Labels: -Action-FeedbackNeeded Needs-Feedback

Comment 10 by, Mar 10 2013

Project Member
Labels: -Area-UI -Feature-Browser Cr-UI-Browser-Core Cr-UI

Comment 11 by, Nov 25 2013

Labels: -Needs-Feedback -Cr-UI-Browser-Core Cr-UI-Aura Cr-UI-Browser-TabStrip
Status: Available
Summary: In Linux, respect the system setting for placement of close/minimize/maximize buttons (was: in linux you're able to choose the side where to have the close minimize and maximize buttons chromium should respect that)
I'm seeing the close/min/max buttons on the wrong side in certain Linux configurations, and it might be related to this issue.

Version: 33 (SVN 237011) (Both GTK and Aura)
OS: Linux (Ubuntu 12.04)

I'm primarily using Unity, where the CMM buttons are on the left for native windows, and Chrome is respecting that. But when I switch to any other shell (Cinnamon, Gnome Shell), the CMM buttons are on the right for native windows, but Chrome is still putting them on the left. It's like Chrome is reading from my Unity configuration even though these other window managers are ignoring it.

I will take a closer look at this.

(Note: While this is an Aura issue, it is also happening on GTK, so I don't consider it a regression.)

Comment 12 by, Nov 26 2013

I think the problem may be that in recent years, Linux desktop environments have forked up where they store this setting. (I don't know if this is germane to the original report from 2009 but that didn't contain any detail anyway.)

We currently respect the gconf setting /apps/metacity/general/button_layout. However, Metacity is no longer used on Gnome Shell / Cinnamon. From what I am reading in various places online (have not confirmed), these desktop environments look for the setting in these places:

Gnome 2: /apps/metacity/general/button_layout (default right)
Unity: /apps/metacity/general/button_layout (default left)
Gnome Shell: /desktop/gnome/shell/windows (default right)
Cinnamon: /desktop/gnome/shell/windows (default right)

Not sure about other desktop environments like Xfce, KDE (maybe they don't even use gconf?).

This is going to be pretty crazy to support properly, but we should at least be able to get the user's preference for the big ones and/or set the correct defaults assuming the user hasn't changed it.

Comment 13 by, Nov 26 2013

KDE and XFCE use totally different preference stores. There are bugs filed on them, but I never spent any time on them. (I say this as a part-time xfce user.)

Comment 14 by, Nov 26 2013

Oh, according to (, in Cinnamon it has now changed to be in /org/cinnamon/overrides/button-layout. Grar!

Comment 15 by, Mar 15 2014

Assigning myself so I get around to this. I just opened  Issue 352896  and found Issue 316342, which I suspect are all mostly the same issue but with varying symptoms. I'll keep all three open (and assigned to myself) for now and investigate.

Since we are no longer working on GTK, this will be treated as an Aura-only bug.

Comment 16 by, Mar 17 2014

Labels: Proj-DesktopAura

Comment 17 by, Mar 17 2014

 Issue 352896  has been merged into this issue.

Comment 18 by, Mar 17 2014

Status: Assigned
It now looks like Ubuntu 13.10 stores this in a different place to older versions. We are looking in:
/apps/metacity/general/button_layout (which was correct for Ubuntu 12.04)
whereas Ubuntu 13.10 seems to store it in:

So confused about the many different settings flags. I'll have another spin around the WMs, figure out which settings are being used, and make Chrome respect all of them in some priority ordering.

Comment 19 by, Mar 17 2014

For reference, I have found in the source code for Ubuntu Tweak (a utility that lets you customize the placement of these buttons) for deciding which of these configs to use, for various desktop environments and versions.

This logic covers the Unity, Gnome Classic and Gnome Shell desktop environments, for Ubuntu 12.04 onwards. The logic (comments mine):

    if system.DESKTOP in ('gnome', 'gnome-shell'):
        # Gnome Shell (not Gnome Classic).
        config = GSetting(key='')
        # Unity, Gnome Classic
        if system.CODENAME == 'precise':
            # <= 12.04
            config = GconfSetting(key='/apps/metacity/general/button_layout')
            # >= 12.10
            config = GSetting(key='org.gnome.desktop.wm.preferences.button-layout')

I think this is a pretty good starting point to use for Chrome (although it doesn't cover more obscure desktop environments like Cinnamon, we can fill those in). A Googler on Issue 316342 says that Cinnamon uses org.gnome.desktop.wm.preferences.button-layout, so that fits the above rule.

Comment 20 by, Mar 17 2014

There are desktops that didn't even use the Gconf or GSettings to store the buttons layout. 

That is the case of XFCE4, as reported in  Issue 62303 , the button layout is stored at


with the format described at

When the layout is changed a D-bus message is sent as reported in

Comment 21 by, Mar 27 2014

Status: Started
I have started work on this and know what the correct behaviour should be. But it is looking unlikely that this will be completed for M35 (not a high priority since it isn't a regression).

Comment 22 by, Sep 25 2014

Issue 316342 has been merged into this issue.

Comment 23 by, Sep 25 2014

Issue 416804 has been merged into this issue.

Comment 24 by, Sep 10 2016

I just wanted to bring this up again as the official Chrome Linux builds now require a fairly recent distribution anyways it seems non-optimal to still depend on gconf: All currently supported systems already come with dconf as a default. Gconf OTOH has been deprecated for some years now which makes Chrome the sole user of Gconf on most recent systems.

Comment 25 by, Sep 10 2016




M - menu
S - on all desktops
I - minimize
A - maximize
X - close
H - context help
L - shade (hides window with only titlebar visible)
B - keep below other windows
F - keep above other windows

Chrome ignores metacity gconf in KDE and is stuck like this:

KDE neon default setup:

macOS/Ubuntu-like titlebar desired to be possible in KDE:

Comment 26 by, Sep 12 2016

Normally, the following command would align the buttons on the left. 

gconftool-2 --set /apps/metacity/general/button_layout --type string "close,minimize,maximize:"

In Chromium 52.0 on Ubuntu 16.04 this no longer works.

Comment 27 by, Sep 12 2016


Comment 28 by, Dec 26 2016

On Chromium 55.0.2883.87 (Developer Build) on Ubuntu 16.04 (64-bit), the following successfully places the buttons on the left

gconftool-2 --set /apps/metacity/general/button_layout --type string "close,minimize,maximize:"

Comment 29 by, Dec 31 2016

Comment 28 suggestion tested with both Chrome and Chromium versioned 55.0.2883.87 on Ubuntu 16.04 based KDE neon (64-bit) - does not work.

Comment 30 by, Jan 1 2017

Re: comment 28, I forgot to mention I'm using the Unity desktop environment.

Comment 31 by, Jan 3 2017

I can confirm that in Chromium 55 it works properly again in elementary OS Loki (64bit), which is based on Ubuntu 16.04. Thanks guys :)

Comment 32 Deleted

Comment 33 by, Mar 30 2017

Moving buttons to right not working in MATE.
AFAIK, there is XDG_CURRENT_DESKTOP checking. Please, add MATE to affected DEs.

Comment 34 by, Apr 18 2017

Owner: ----
Status: Available (was: Started)

Comment 35 by, Apr 27 2017

Does "Status: Available" mean this will land in Chrome 59?

I can confirm this is not working in Chrome 58 using Debian 8. In my case, I want to remove all of the window buttons. After setting "gsettings set org.gnome.desktop.wm.preferences button-layout 'appmenu:'" Chrome still displays the minimize, maximize, close buttons in the right corner.

These window buttons simply aren't needed in Gnome-Shell. And I use Chrome Profiles, so it is not helpful to have those window buttons pushing the Profile name farther to the left. And although enabling Chrome > Settings > Use system title bar and borders removes the window buttons, it adds a big huge useless Titlebar above the tab-bar. So this bug-fix seems the best solution.

Comment 36 by, Apr 27 2017

Any chance a developer has room to take this on? Pretty please? ;-)

Comment 37 by, Apr 27 2017

Status: Assigned (was: Available)
Working on this now, have no fear.

Chromium will soon rely on GTK for the titlebutton ordering.  No longer will we read various gconf settings that are scattered everywhere

Comment 38 by, Apr 27 2017

Thanks Thomas - will this have any impact on the libunity titlebar issue?

Comment 39 by, Apr 27 2017

Unfortunately it will not fix that issue

Comment 40 by, Jul 16 2017

After updating to 59, the issue is back again :/ It was working before, since 55, where it got fixed for me (elementaryOS Loki 64bit, based on Ubuntu 16.04, kernel 4.4, GTK+ 3.18.9).

Comment 41 by, Aug 21 2017

Blocking: 753067

Comment 42 by, Aug 24 2017

Project Member
The following revision refers to this bug:

commit 16dfbe80f2f54e86899e5ec96032d4450f541c1e
Author: Tom Anderson <>
Date: Thu Aug 24 20:09:13 2017

Use GTK frame button layout when available

BUG= 21438

Change-Id: I9c596a297a48ab7b4405fbe13b99ddede99c5d54
Commit-Queue: Thomas Anderson <>
Reviewed-by: Elliot Glaysher <>
Cr-Commit-Position: refs/heads/master@{#497169}

Comment 43 by, Aug 25 2017

Project Member
The following revision refers to this bug:

commit b1699100facc4616a97e1f190cee0fc333d20c27
Author: Tom Anderson <>
Date: Fri Aug 25 17:38:11 2017

Gtk: Explicitly track if nav buttons are set in GtkUi

GtkUi used to implicitly track if the nav button layout was set by
checking if the button layout was nonempty.  This caused a bug where
the button layout would incorrectly display the default button layout
(minimize, maximize, and close all on the right) when Chrome was
launched and the GTK setting had no frame buttons.

Note that it was still possible to get Chrome to display no frame
buttons if you changed the GTK setting after Chrome was launched.

BUG= 21438

Change-Id: Ie9f9f4d72b2009b600f50eda4c647dc20e2d5196
Reviewed-by: Elliot Glaysher <>
Commit-Queue: Thomas Anderson <>
Cr-Commit-Position: refs/heads/master@{#497456}

Comment 44 by, Aug 29 2017

 Issue 62303  has been merged into this issue.

Comment 45 by, Aug 29 2017

Project Member
The following revision refers to this bug:

commit 9fff344076c8ae00884c22ac8e5093c47d3b9fba
Author: Tom Anderson <>
Date: Tue Aug 29 01:48:47 2017

Enable GTK native nav button drawing and layout on GTK3.14+

BUG= 753067 , 21438

Change-Id: I383b1e623b067033a0376d86cd7a758aba23d25b
Reviewed-by: Elliot Glaysher <>
Commit-Queue: Thomas Anderson <>
Cr-Commit-Position: refs/heads/master@{#497981}

Comment 46 by, Oct 17 2017

 Issue 353021  has been merged into this issue.

Comment 47 by, Nov 2 2017


Comment 48 by, Nov 2 2017

X-reffing images for CL
9.2 KB View Download
8.4 KB View Download
10.4 KB View Download
9.2 KB View Download

Comment 49 by, Nov 10 2017

Status: Fixed (was: Assigned)
This should be fixed in Chrome version 62 or later when using GTK 3.14+.

If you believe the issue is still not fixed on your system: please note the following:
* Gtk 3.13 and earlier still fallback to the old gconf codepath.  We are not changing this.
* Chrome now obtains the button layout from GTK.  Please test with gtk3-widget-factory and note its button layout.  Only if the button layout there differs from Chrome should you file a bug.

Notes on how to change your system button layout:
* GTK orders buttons based on the gtk-decoration-layout setting.  The format for this setting is specified at
* gtk-decoration-layout is backed by an xsetting called Gtk/DecorationLayout.  Your xsettings daemon is what provides this property, so instructions on how to change the setting are dependent on which daemon you're using.  Here are some examples:
* If you're using gnome-settings-daemon:
    $ gsettings set org.gnome.desktop.wm.preferences button-layout 'menu:minimize,maximize,close'
* If you're using cinnamon-settings-daemon:
    $ gsettings set org.cinnamon.desktop.interface gtk-decoration-layout 'menu:minimize,maximize,close'

Sign in to add a comment