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 51 users
Status: Fixed
Owner:
Closed: Mar 2
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression



Sign in to add a comment
Windows not properly grouped in Gnome Shell task switcher
Reported by ironclad...@gmail.com, May 29 2014 Back to list
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36

Steps to reproduce the problem:
1. Install google-chrome-stable
2. Launch two Chrome windows

What is the expected behavior?
A single 'Google Chrome' application in the switcher, with all windows grouped below in a submenu.

What went wrong?
Observe multiple task switcher entries labeled 'Google-chrome-s...'.

Did this work before? Yes Prior to the Aura changes.

Chrome version: 35.0.1916.114  Channel: stable
OS Version: Fedora 20
Flash Version: Shockwave Flash 13.0 r0

The problem is that the .desktop filename in /usr/share/applications/google-chrome.desktop doesn't match the WM_CLASS xprop of the Chrome windows: "Google-chrome-stable".  Renaming the .desktop file to /usr/share/applications/google-chrome-stable.desktop corrects the issue.
 
Comment 1 by msw@chromium.org, May 29 2014
Cc: e...@chromium.org mgiuca@chromium.org
Labels: -Type-Bug Type-Bug-Regression Proj-DesktopAura Cr-Internals-Aura Cr-UI-OSIntegration
Hey Elliot and Matt, can you follow up here?
Comment 2 by magc...@gmail.com, May 29 2014
This is because Aura Chrome doesn't set WM_CLASS anymore.

Something like the following should work:

    XClassHint wm_hints;
    wm_hints.res_name = PACKAGE_FILENAME;
    wm_hints.res_class = PACKAGE_FILENAME;

And then changing the call to XSetWMProperties here:

    http://git.chromium.org/gitweb/?p=chromium.git;a=blob;f=ui/aura/window_tree_host_x11.cc;h=1db7136a0d90ccf09976bacc7f600990a2dae4d3;hb=HEAD#l286
Comment 3 by e...@chromium.org, May 29 2014
So, at least on Version 37.0.2017.2 dev, if I do:

$ xprop  | grep WM_CLASS
WM_CLASS(STRING) = "Google-chrome-unstable (/usr/local/google/home/erg/.config/google-chrome-unstable)", "Google-chrome-unstable"

We appear to be setting the WM_CLASS at a combination of browser_frame.cc (See BrowserFrame::InitBrowserFrame()), and desktop_root_window_tree_host_x11.cc (See DesktopWindowTreeHostX11::InitX11Window()). All the code that deals with this looks like it was added in late 2013, so it should already be in M35.

I am confused.

Can you reproduce this on the dev channel?
My (very limited) understanding from a brief discussion in #gnome-shell is that there's an implied correlation between WM_CLASS and the actual filename of the .desktop filename.  Whether the current WM_CLASS value should be modified to reflect the .desktop filename or whether the .desktop filename should be changed in the packaging to match the WM_CLASS value is unknown to me.

Sorry I don't have more details.  All I have is observed behavior and a fix which works, but no knowledge of what the appropriate course of action is (as I have no intimate knowledge of Gnome's guts).

Thanks for looking into this!
Comment 5 by magc...@gmail.com, May 29 2014
> $ xprop  | grep WM_CLASS
> WM_CLASS(STRING) = "Google-chrome-unstable (/usr/local/google/home/erg/.config/google-chrome-unstable)", "Google-chrome-unstable"

This looks wrong to me. This would make gnome-shell look for /usr/share/applications/google-chrome-unstable.desktop

On my system, the .desktop file is shipped as /usr/share/applications/google-chrome.desktop.

It seems that GetProgramClassName() is returning argv[0], when it should really be the same as the .desktop name.
Comment 6 by e...@chromium.org, May 29 2014
Owner: mgiuca@chromium.org
Status: Assigned
Assigning to mgiuca@ since he knows all this stuff and I don't.
Comment 7 by mgiuca@chromium.org, May 30 2014
Mergedinto: 174794
Status: Duplicate
This is a duplicate of a very old bug ( Issue 174794 ). You can follow the discussion on there.

The end result of that bug was that we concluded it was a Gnome Shell bug (they did not respect WM_CLASS properly). Here is the upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=673657

Last I heard (August 2013), they fixed the bug in their tip-of-tree, which means you'd need a version of Gnome Shell that was released after August to have the fix. I'm not sure which version of Gnome Shell was packaged with Fedora 20. @ironcladlou: Can you figure out which version of Gnome Shell you're running?

I never actually tested this fix with a new version of Gnome Shell to know whether it worked or not. Please continue the discussion on  Issue 174794 .
Comment 8 by magc...@gmail.com, May 30 2014
I don't see any StartupWMClass in the google-chrome.desktop desktop file.
Comment 9 by mgiuca@chromium.org, May 30 2014
Mergedinto:
Owner: phajdan.jr@chromium.org
Status: Assigned
Oh sorry, I see this isn't about Chrome apps, but browser windows. Removing duplicate status.

On my system (Ubuntu 12.04), the desktop file is installed as:
/usr/share/applications/google-chrome-unstable.desktop

Which is the correct filename; it matches the name of the binary and the second component of WM_CLASS. All of that is correct. (I haven't actually tested with Gnome Shell, but I think it will work.)

> It seems that GetProgramClassName() is returning argv[0], when it should really be the same as the .desktop name.

This is the correct behaviour. The program class name is the binary name. The .desktop name should match the binary name.

It looks like both @ironcladau and @magcius have got the wrong .desktop filenames. @ironcladau is using Fedora, so maybe the .rpm package is bad while the .deb package is good. +phajdan.jr: Do you know anything about the .rpm packaging side?

Are you guys both using an official build of Google Chrome? If you are using a distro-specific build of Chromium, then we can't help you -- this is an issue you should raise with the package maintainer of Chromium for your distro.
@mgiuca

I'm getting Chrome from an official repo: http://dl.google.com/linux/chrome/rpm/stable/x86_64

The version I'm currently using is google-chrome-stable-35.0.1916.114-1.x86_64.


Ah, so I think this is an issue with our official .rpm then (and not our .deb). PaweĊ‚, would you be able to look into it?
Cc: phajdan.jr@chromium.org
Owner: ----
Status: Available
I'm mostly swamped with infra work at this time, sorry.
I just noticed the same issue on Chrome 37 stable (.deb package). The WM_CLASS is set as

WM_CLASS(STRING) = "Google-chrome-stable", "Google-chrome-stable"

(name of the binary starting it), but the desktop file shipped in the stable deb is google-chrome.desktop, so matching fails. Changing WM_CLASS to "google-chrome" makes it work correctly.

The non-stable chrome builds ship their desktop files under a matching name, thus no problem there. Renaming the desktop file seems to be the best option, although this would require a fix for users directly using the google-chrome command from the terminal, as then the WM_CLASS would be "google-chrome" again.

So, in the end, you most likely want to hard-code the WM_CLASS somewhere, so it does not change if you call google-chrome or google-chrome-stable.

Step to reproduce:
(0. Have Chrome in your GNOME Shell favourites)
1. Start Chrome
2. Restart Gnome shell
Result:
1. An extra icon appears in the dock
2. Chrome is listed as Google-chrome-stable in the Shell's app menu (top-left)
Expected:
1. The window is linked to the existing favourite Chrome icon
2. Chrome is listed as "Google Chrome" in the Shell's app menu

Comment 14 by ipet...@gmail.com, Dec 3 2014
I have this issue. I am running on Fedora (20, and then later the not-quite-released-yet 21), and have installed google-chrome-stable from the Google Chrome yum repo that points at http://dl.google.com/linux/chrome/rpm/stable/x86_64.

The suggested fix, renaming the google-chrome.desktop file to google-chrome-stable.desktop, works perfectly to resolve the issue. I see that the last update here was over two months ago; is there any reason not to rename the .desktop file as shipped in the package?
phajdan.jr: Would you have time to take a look at this now? I think it's just about renaming the desktop files in the RPM distro of Chrome.
Sorry, I really have no cycles for this at this point. I did produce https://codereview.chromium.org/410413004/ but it's stuck in review and I'm out of cycles to do things arguably out of scope for that CL.
This is a major pain point of users in elementary OS as well. Our system dock, Plank, also uses the StartupWMClass to determine if the app should be grouped under an existing app icon on the dock, and Google Chrome ends up creating a duplicate (blurry) icon.
I get the same issue using Ubuntu 14.04LTS and Chrome Version 41.0.2272.118, downloaded through the Ubuntu repositories. Other Ubuntu users are experiencing dual icons for Chrome as well. (For example, see http://askubuntu.com/questions/396448/google-chrome-opens-in-a-new-window-in-a-new-launcher-icon.) 

So, it would seem that both debian and rpm versions of Chrome are affected by this bug.
julian.k seems to have a good suggestion re hard-coding the WM_CLASS. It'd be great to see this implemented in the released packages. My workaround in the meantime has been:

-----------Workaround Start-----------

Open a terminal and type:

sudo gedit /usr/share/applications/google-chrome.desktop

You'll find 3 sections in this file, [Desktop Entry], [NewWindow Shortcut Group] and [NewIncognito Shortcut Group]. Make sure that under each section there's the following line, it doesn't matter where in the section it is.

StartupWMClass=Google-chrome-stable

--------Workaround Finish----------------

Of course I have to repeat this workaround after each upgrade of chrome/chromium.
Owner: mgiuca@chromium.org
Status: Assigned
I will try to look into this at some point (but I am also occupied with non-Linux-related work at the moment).
Comment 21 by mru...@gmail.com, Jun 5 2015
@tcol
> Of course I have to repeat this workaround after each upgrade of chrome/chromium.

More update-independent solution would be to copy google-chrome.desktop file into ~/.local/share/applications and apply your workaround there.
Comment 22 Deleted
Its happening to me at Gnome 3.12 and Ubuntu 14.04 and Gnome 3.16 at Ubuntu 15.04, both under Version 43.0.2357.124 (64-bit) . But, at the Gnome 3.16 and 3.12, i cant "Add to favorites" the browser, under the left sidebar of gnome.

Same here... Common Google, get you QA right ;-)

[keesj@defiant ~]$ rpm -q gnome-shell
gnome-shell-3.16.2-1.fc22.x86_64

[keesj@defiant ~]$ rpm -q google-chrome-stable
google-chrome-stable-43.0.2357.130-1.x86_64

[keesj@defiant ~]$ cat /etc/redhat-release 
Fedora release 22 (Twenty Two)

#23 You can still favorite it by clicking "Show applications" in gnome-shell and right clicking it there, but the issue of a separate icon when you launch it still remains.
OH COME ON GOOGLE! FIX IT FOR GOOD!!! Seems like I am back on FF on my Fedora 22....
Same here, issue is back.

[root@defiant ~]# cat /etc/redhat-release 
Fedora release 22 (Twenty Two)
[root@defiant ~]# rpm -q google-chrome-stable
google-chrome-stable-44.0.2403.89-1.x86_64
[root@defiant ~]# date
Fri Jul 24 10:27:08 CEST 2015

Comment 28 by Deleted ...@, Jul 26 2015
I can confirm the issue also.

Fedora Core 22
Linux localhost 4.0.8-300.fc22.x86_64 #1 SMP Fri Jul 10 21:04:56 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
gnome-shell-3.16.3-1.fc22.x86_64
google-chrome-stable-44.0.2403.107-1.x86_64

"#20 mgiuca@chromium.org
I will try to look into this at some point (but I am also occupied with non-Linux-related work at the moment)."

Well the answer is already given:
sudo gedit /usr/share/applications/google-chrome.desktop

You'll find 3 sections in this file, [Desktop Entry], [NewWindow Shortcut Group] and [NewIncognito Shortcut Group]. Make sure that under each section there's the following line, it doesn't matter where in the section it is.

StartupWMClass=Google-chrome-stable



Implement that in the package and you're done.....

Just upgraded to google-chrome-stable-44.0.2403.125-1.x86_64, still not fixed.
Comment 30 by Deleted ...@, Jul 31 2015
I confirm the change on answer #29 fixes the issue. Please mainline it.
Comment 31 by Deleted ...@, Aug 12 2015
#29 seems to fix the problem perfectly. Chrome can be added to GNOME 3 favorites, and no second icon will appear after launching it.
Comment 32 by magc...@gmail.com, Aug 12 2015
Note that StartupWMClass is considered deprecated and might go away upstream at some point, since it requires us to load every single .desktop file to parse out the WM classes inside.
@32 if it's considered deprecated, then there should be a replacement. Chrome is the only application that behaves this way. Please fix it, we don't care how. But at least fix this minor issue.

And we're talking about Chrome here, 'it requires us to load every single .desktop file to parse out the WM classes inside'. Chrome already uses most RAM on any system. So parsing a few txt files wouldn't hurt...
Comment 34 by magc...@gmail.com, Aug 12 2015
The replacement is to rename the .desktop file to google-chrome-stable.desktop, as has been described above.

Loading every .desktop file at startup has a measurable bit of IO that is extremely bad for boot speed, especially on spinning rust disks.
@34 that's not the right fix, then Gnome can't associate the application anymore if you do that. You can test this when you go to gnome-settings --> details --> default applications --> web. There you won't find Chrome.
It is the right fix, some other file just beeds to be updated as well.
Comment 37 by a...@chromium.org, Sep 1 2015
Cc: ssamanoori@chromium.org
 Issue 508491  has been merged into this issue.
Same problem here, StartupWMClass=Google-chrome-stable fixes it for me.
Yes, StartupWMClass=Google-chrome-stable' in the google-chrome.desktop file fixes it for me too. I have to add it after every update though.
I have used this script after every update: https://github.com/erichnascimento/fix-chrome-window-group-gnome-shell
Is it just me or have Google engineers taken more time explaining how they haven't got time to fix this issue than it would have taken to fix this issue?
Is it just me or have Google engineers taken more time explaining how they haven't got time to fix this issue than it would have taken to fix this issue?
If you want a workaround that survives updates, see Comment#21. It works for me.
Comment 44 by Deleted ...@, Sep 28 2015
It does not work for me with Gnome 3.16 on FreeBSD.  Since I am running the open source chromium, and not chrome would my startup class need to be something other than StartupWMClass=Google-chrome-stable?
Re Chromium on FreeBSD, I'm no expert, but I suggest check the . desktop file or equivalent for chromium and see if it already has a phrase starting with "StartupWMClass=". If so, just replicate that phrase to the places mentioned in the workaround. If not, create your own unique value for this phrase (i.e. dissimilar to other applications) and paste the phrase into the same places.
Comment 46 by Deleted ...@, Sep 30 2015
That's what I did.  It doesn't work.  ^
That's fixed in Chrome 46, the browser window now reports:

WM_CLASS(STRING) = "google-chrome", "google-chrome"

Cc: thomasanderson@chromium.org
Components: -UI
Components: -UI>OSIntegration Internals>PlatformIntegration
Deprecating UI>OSIntegration in favor of the more generic Internals>PlatformIntegration
Status: Fixed
I believe this is fixed at this point.  Please let me know if it's not so I can reopen.
Waiting for my new  XPS 15, in a couple of weeks will be able to verify and close.


Sign in to add a comment