Project: chromium Issues People Development process History Sign in
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
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Blocking:
issue 753067


Show other hotlists

Hotlists containing this issue:
ZapList


Sign in to add a comment
In Linux, respect the system setting for placement of close/minimize/maximize buttons
Reported by luis.da...@gmail.com, Sep 10 2009 Back to list
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 calebegg@gmail.com, May 16 2011
Labels: -OS-All -Area-Misc OS-Linux Area-UI Feature-Browser
Comment 2 by e...@chromium.org, 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 laum@chromium.org, May 19 2011
Cc: laum@google.com
Status: Untriaged
Comments from developers ?
Comment 4 by e...@chromium.org, May 19 2011
Cc: evan%chr...@gtempaccount.com
@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 evan@chromium.org, 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 evan@chromium.org, 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.
Cc: -laum@google.com
Comment 8 by evan@chromium.org, Jun 11 2012
Cc: -evan@chromium.org
(Un-ccing myself from bugs.)
Project Member Comment 9 by bugdroid1@chromium.org, Mar 9 2013
Labels: -Action-FeedbackNeeded Needs-Feedback
Project Member Comment 10 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-UI -Feature-Browser Cr-UI-Browser-Core Cr-UI
Cc: mgiuca@chromium.org e...@chromium.org
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.)
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 e...@chromium.org, 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.)
Oh, according to (http://askubuntu.com/questions/99866/how-to-switch-the-window-buttons-to-the-left-in-cinnamon), in Cinnamon it has now changed to be in /org/cinnamon/overrides/button-layout. Grar!
Owner: mgiuca@chromium.org
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.
Labels: Proj-DesktopAura
 Issue 352896  has been merged into this issue.
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:
org/gnome/desktop/wm/preferences/button_layout

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

https://github.com/tualatrix/ubuntu-tweak/blob/master/ubuntutweak/tweaks/window.py

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='org.gnome.shell.overrides.button-layout')
    else:
        # Unity, Gnome Classic
        if system.CODENAME == 'precise':
            # <= 12.04
            config = GconfSetting(key='/apps/metacity/general/button_layout')
        else:
            # >= 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 ch...@igalia.com, 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

~/.config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml

with the format described at http://wiki.xfce.org/howto/xfwm4_theme#button_layout

When the layout is changed a D-bus message is sent as reported in https://code.google.com/p/chromium/issues/detail?id=62303#c24
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).
Cc: agautam@chromium.org tkonch...@chromium.org ashej...@chromium.org
Issue 316342 has been merged into this issue.
Cc: a...@chromium.org
Issue 416804 has been merged into this issue.
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.
KDE

~/.config/kwinrc

[org.kde.kdecoration2]
ButtonsOnLeft=
ButtonsOnRight=

values
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:
ButtonsOnLeft=
ButtonsOnRight=IAX

KDE neon default setup:
ButtonsOnLeft=M
ButtonsOnRight=IAX

macOS/Ubuntu-like titlebar desired to be possible in KDE:
ButtonsOnLeft=XIA
ButtonsOnRight=
Comment 26 by m...@rahidelvi.ca, 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.


Cc: thomasanderson@chromium.org
Comment 28 by m...@rahidelvi.ca, 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 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 m...@rahidelvi.ca, Jan 1 2017
Re: comment 28, I forgot to mention I'm using the Unity desktop environment.
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
Moving buttons to right not working in MATE.
AFAIK, there is XDG_CURRENT_DESKTOP checking. Please, add MATE to affected DEs.
Owner: ----
Status: Available
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.
Any chance a developer has room to take this on? Pretty please? ;-)
Owner: thomasanderson@chromium.org
Status: Assigned
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
Thanks Thomas - will this have any impact on the libunity titlebar issue?
 https://bugs.chromium.org/p/chromium/issues/detail?id=594490


Unfortunately it will not fix that issue
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).
Blocking: 753067
Project Member Comment 42 by bugdroid1@chromium.org, Aug 24
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/16dfbe80f2f54e86899e5ec96032d4450f541c1e

commit 16dfbe80f2f54e86899e5ec96032d4450f541c1e
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Thu Aug 24 20:09:13 2017

Use GTK frame button layout when available

BUG=21438
R=erg@chromium.org

Change-Id: I9c596a297a48ab7b4405fbe13b99ddede99c5d54
Reviewed-on: https://chromium-review.googlesource.com/629317
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Elliot Glaysher <erg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497169}
[modify] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/BUILD.gn
[modify] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/gtk_ui.cc
[modify] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/gtk_ui.h
[modify] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/gtk_util.cc
[modify] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/gtk_util.h
[add] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/nav_button_layout_manager.h
[rename] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/nav_button_layout_manager_gconf.cc
[rename] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/nav_button_layout_manager_gconf.h
[add] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/nav_button_layout_manager_gtk3.cc
[add] https://crrev.com/16dfbe80f2f54e86899e5ec96032d4450f541c1e/chrome/browser/ui/libgtkui/nav_button_layout_manager_gtk3.h

Project Member Comment 43 by bugdroid1@chromium.org, Aug 25
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b1699100facc4616a97e1f190cee0fc333d20c27

commit b1699100facc4616a97e1f190cee0fc333d20c27
Author: Tom Anderson <thomasanderson@chromium.org>
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
R=erg@chromium.org

Change-Id: Ie9f9f4d72b2009b600f50eda4c647dc20e2d5196
Reviewed-on: https://chromium-review.googlesource.com/633837
Reviewed-by: Elliot Glaysher <erg@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497456}
[modify] https://crrev.com/b1699100facc4616a97e1f190cee0fc333d20c27/chrome/browser/ui/libgtkui/gtk_ui.cc
[modify] https://crrev.com/b1699100facc4616a97e1f190cee0fc333d20c27/chrome/browser/ui/libgtkui/gtk_ui.h

Cc: thestig@chromium.org
 Issue 62303  has been merged into this issue.
Project Member Comment 45 by bugdroid1@chromium.org, Aug 29
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9fff344076c8ae00884c22ac8e5093c47d3b9fba

commit 9fff344076c8ae00884c22ac8e5093c47d3b9fba
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Tue Aug 29 01:48:47 2017

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

BUG=753067,21438
R=erg@chromium.org

Change-Id: I383b1e623b067033a0376d86cd7a758aba23d25b
Reviewed-on: https://chromium-review.googlesource.com/636039
Reviewed-by: Elliot Glaysher <erg@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497981}
[modify] https://crrev.com/9fff344076c8ae00884c22ac8e5093c47d3b9fba/chrome/browser/ui/libgtkui/gtk_ui.cc
[modify] https://crrev.com/9fff344076c8ae00884c22ac8e5093c47d3b9fba/chrome/common/chrome_features.cc

Comment 46 by thomasanderson@chromium.org, Oct 17 (5 days ago)
Cc: benwells@chromium.org
 Issue 353021  has been merged into this issue.
Sign in to add a comment