Issue 676900  has been merged into this issue.

I've opened a libunity bug report
https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1663747

 Issue 700850  has been merged into this issue.

 issue 375650  is a duplicate

 Issue 375650  has been merged into this issue.

I just got report of this happening on Elementary OS now.  Since so many people are hitting this issue, I think we should further investigate possible workarounds.

I have had this bug for years, but finally found a usable workaround recently from another thread.  My configuration is different, but hopefully the workaround may still work here.  My configuration is Gnome, Compiz, cairo-dock, with Unity turned off (but libunity still installed).  I was able to resolve the issue by launching Chrome as follows:

env XDG_CURRENT_DESKTOP=GNOME google-chrome

In this case, maybe 'GNOME' should be replaced with e.g. 'KDE', but I believe anything works as long as chrome doesn't think it is Unity.

From  Bug #375650 

The bug is in 

https://chromium.googlesource.com/chromium/src/+/master/ui/views/window/custom_frame_view.cc

bool ChromeViewsDelegate::WindowManagerProvidesTitleBar(bool maximized) {
  // On Ubuntu Unity, the system always provides a title bar for maximized
  // windows.
  views::LinuxUI* ui = views::LinuxUI::instance();
  return maximized && ui && ui->UnityIsRunning();
}

It assumes all linux desktops which support libunity, which provides an API for the taskbar progress overlay and a download count badge, provide a global titlebar w/ buttons.

We need it to do the same check it does in unity_service.cc linked below.

using base::nix::GetDesktopEnvironment;
std::unique_ptr<base::Environment> env(base::Environment::Create());
base::nix::DesktopEnvironment desktop_env = GetDesktopEnvironment(env.get());
if (desktop_env == base::nix::DESKTOP_ENVIRONMENT_KDE5)
    return false;


Ideally, chrome should check ~/.config/kwinrc for 
[Windows]
BorderlessMaximizedWindows=true

though that would be a much more complicated change.


Relevant: 

CustomFrameView::ShouldShowTitleBarAndBorder() calls ChromeViewsDelegate::WindowManagerProvidesTitleBar(bool maximized) linked above.
https://chromium.googlesource.com/chromium/src/+/master/ui/views/window/custom_frame_view.cc

The unity singleton is defined here, and is loaded for both Unity, KDE4, and KDE5.
https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/ui/libgtkui/unity_service.cc#65

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0960ecfad7787c492f407054c9a9ba1b7134ef5d

commit 0960ecfad7787c492f407054c9a9ba1b7134ef5d
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Wed Sep 27 18:04:39 2017

Use XDG_CURRENT_DESKTOP to determine if the desktop environment is Unity

chrome_views_delegate_linux.cc used to ask libunity if it was running
to determine if the desktop environment is Unity.  This is incorrect
because other environments might use libunity (eg. for download
progress indicators).  Instead, check if XDG_CURRENT_DESKTOP indicates
the environment is Unity.

This CL's behavior differs from the way GTK checks if it needs to
remove the frame buttons.  The way canonical achieved this is with an
Ubuntu-specific GTK patch.  Unity adds _UNITY_SHELL to _NET_WM_HINTS,
and the patched GTK checks if that hint is set on the root window that
contains the GTK window.  This solution is more correct than what this
CL does because it handles the case where chrome is launched with
"DISPLAY=:1 google-chrome-stable", where display :1 might be running a
different environment than the display Chrome was launched from.
However, this hint is only set on GTK 3.18+, but we still support
Trusty (maximized GTK windows on Trusty do not remove the frame
buttons), so we're forced to use the XDG_CURRENT_DESKTOP solution.

This CL:
* Removes LinuxUi::UnityIsRunning.
* Uses the XDG_CURRENT_DESKTOP solution in
  chrome_views_delegate_linux.cc
* Adds a TODO for when we'll be able to use the _UNITY_SHELL solution.

BUG= 594490 
R=erg@chromium.org

Change-Id: I4922e5e3283f4549209bd27218a7032842219d6a
Reviewed-on: https://chromium-review.googlesource.com/682615
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Elliot Glaysher <erg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504727}
[modify] https://crrev.com/0960ecfad7787c492f407054c9a9ba1b7134ef5d/chrome/browser/ui/libgtkui/gtk_ui.cc
[modify] https://crrev.com/0960ecfad7787c492f407054c9a9ba1b7134ef5d/chrome/browser/ui/libgtkui/gtk_ui.h
[modify] https://crrev.com/0960ecfad7787c492f407054c9a9ba1b7134ef5d/chrome/browser/ui/views/chrome_views_delegate_linux.cc
[modify] https://crrev.com/0960ecfad7787c492f407054c9a9ba1b7134ef5d/ui/views/linux_ui/linux_ui.h

Requesting merge to M62.  This is not a regression, but it would be nice to have fixed

This bug requires manual review: M62 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this well tested in Canary and unit tests? My recommendation is to wait until M63, since this doesn't seem to be a blocker and we're few weeks away from stable promotion.  

c#12: No and no.  We can wait in that case.

The fix will appear in Chrome 63 or later.

Thanks!

This doesn't work for elementary OS (which uses the Pantheon desktop environment) on Chrome 63. On elementary OS the window buttons are not present when the Chrome window is maximized. I believe it may be because XDG_CURRENT_DESKTOP is set to "Pantheon" (that is the exact value including the capital letter, excluding quotes) on elementary OS.

Running Chrome with XDG_CURRENT_DESKTOP set to "GNOME" solves the problem however (i.e. displays the window buttons as expected). The window button padding when maximized is a little off with this fix, but that's obviously less important than having the window buttons there in the first place.

c#15: The change hasn't yet made it into the latest dev release.  It's only in 63.0.3227.0 and later.

Ah, sorry, I didn't know that. Thank you!

c#15 and c#17, you were right all along!  The bug still exists when XDG_CURRENT_DESKTOP="Pantheon", because we apparently pretend that Pantheon is Unity:
https://cs.chromium.org/chromium/src/base/nix/xdg_util.cc?rcl=d0792561cd76c39fee44fb509a64029a000fe65a&l=63

We'll try to have this fixed soon over at  bug 773233 .