Google Chrome applications do not play nice with Docky

[ChrisTomalty]

When creating a web application in Google Chrome, Docky does not handle the new launcher properly.

Steps for replication (and the only way to explain it)
1. Open Google Chrome
2. Turn a page into a webapp by pressing the page icon and Create Application Shortcut. Create one to the desktop
3. Drag the desktop icon onto Docky.

Notice how whenever Chrome is open it says that the webapp is also open, similarly when the webapp is the only one open it treats the browser as open also. The real trouble comes when both are open, and clicking either icon is just like if you had multiple Chrome windows open, rendering webapps extremely inconvenient.

Running Ubuntu 9.10 64 bit, default settings except for Spatial Desktop, which doesn't modify application files/X version/Mono/etc
Intel Graphics Media Accelerator (128 MB)
Dell Inspiron 1525
GNOME 2.28
Docky 2.0.0-Alpha-1 docky-2.0~bzr615

Screencast available upon request

[Robert Dyer (psybers)]

The problem is that both 'apps' are really the same program. Thus Docky will group them accordingly. We may or may not make special rules to handle this.

[nicky.7 (nickkkk7)]

I think we need a "special rule" for this, prism (firefox app) and also other such as im program.
A per-application option could be a good option?

[Ryan Thompson (rct86)]

I know this is possible, because I made it work in Docky 1 (Gnome Do). I got both Prism webapps and Google Chrom webapps to appear as separate applications.

[nicky.7 (nickkkk7)]

Can you tell me how you did it? Maybe I can build a patch!

On 8 March 2010 18:21, Ryan Thompson <email address hidden> wrote:

> I know this is possible, because I made it work in Docky 1 (Gnome Do). I
> got both Prism webapps and Google Chrom webapps to appear as separate
> applications.
>
> --
> Google Chrome applications do not play nice with Docky
> https://bugs.launchpad.net/bugs/488958
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Nat Budin (natbudin)]

One workaround I have used before is to create separate copies (NOT symlinks) of the chromium.bin executable, and make launchers use those instead of the system chromium.bin. But this is annoying to deal with on upgrades and also doesn't scale particularly well to lots of web app launchers.

[Ryan Thompson (rct86)]

I got it working with Docky 2, but then today's update (2.1.0~bzr1220-0ubuntu1~9.10~dockycore1) broke my solution. To be clear, the solution I'm describing worked with Docky 2 until today.

I did things with creative symlinks. First, each webapp has a dedicated directory. Here's the example for google reader. This is actually the directory that Mozilla's Prism creates on its own. But notice that I have added a symlink to prism-bin, with the name of the webapp I want to run. In this case, I've named it greader. There is a launcher script, whose contents are detailed below. This launcher is symlinked into my $PATH with the *same basename* as the symlink to prism-bin. So there are two symlinks involved: one symlink in a discrete location pointing to prism-bin, and another symlink with the same basename pointing to the launcher script. Finally, create a .desktop file in ~/.local/share/applications that uses the symlink in $PATH. Now, when I run greader, I end up with a process whose name appears to be greader, which matches the name in the .desktop file, so Docky is happy. Until today, that is.

Anyway, I'll attach a shell transcript that demonstrates all this.

[Ryan Thompson (rct86)]

Did someone push an update recently that allows Docky to resolve symlinks and figure out the real program name? Because that would break the solution I described.

[Robert Dyer (psybers)]

No, it doesnt resolve symlinks.

[Ryan Thompson (rct86)]

Well, something must have changed recently, because my solution used to work, and now when I start a Prism webapp, the window is grouped under the Prism icon instead of my custom icon for the webapp. I guess this broke on 2010-03-29, which is what prompted me to visit this bug and make my post on that date.

[Robert Dyer (psybers)]

Prism probably sets StartupWMClass in its launcher.

[Steve Baker (steve-stevebaker)]

I've filed this issue to get this fixed on the Chromium side:
http://code.google.com/p/chromium/issues/detail?id=42587

[Ryan Thompson (rct86)]

How can I view the StartupWMClass and other such attributes of an open window? I'd like to investigate further to try and find a new workaround.

[Robert Dyer (psybers)]

Run 'xprop' from a terminal and then click on the window. The StartupWMClass is set to the (2nd) value of WM_CLASS. For example:

WM_CLASS(STRING) = "Navigator", "Firefox"

and you can see in firefox.desktop:

StartupWMClass=Firefox

[Robert Dyer (psybers)]

Let me be perfectly clear about this bug, there is little we (Docky devs) can do about it at this point. With what Chrome sets on its windows currently, there is no fun hack to get around this.

The only alternative (that some of you asked for) is to just simply allow ungrouping of certain applications, such as Chrome. The problem here however is that even though they would be ungrouped, they would all point to the same .desktop file and thus you would see 3 'chrome' icons on your dock, not 1 chrome icon + 2 chrome app items with their own unique icons. To me this is just as confusing and thus you really don't gain anything and it does not support the complexity it would add to our codebase.

The simple fix is to get Chrome to allow setting the WM_CLASS. Considering they have something like 14k open bugs though, don't hold your breath on them getting around to that.

[Robert Dyer (psybers)]

Confirmed with Jason. This is *not possible* in Docky without a Chrome extension.

He is implementing support in BAMF. If/when he finishes that and we switch Docky to using BAMF this will be supported.

[nicky.7 (nickkkk7)]

I suppose i have to open another bug in order to talk about prism (firefox)
application having all the same icon..

On 9 June 2010 22:01, Robert Dyer <email address hidden> wrote:

> Confirmed with Jason. This is *not possible* in Docky without a Chrome
> extension.
>
> He is implementing support in BAMF. If/when he finishes that and we
> switch Docky to using BAMF this will be supported.
>
> --
> Google Chrome applications do not play nice with Docky
> https://bugs.launchpad.net/bugs/488958
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Robert Dyer (psybers)]

Correct.

[Colin Keenan (colinkeenan)]

I have started looking into this problem again because Docky has decided all my chromium applications should use the TV-Guide icon. I found that icon located in

~/.local/share/icons/hicolor/16x16/apps

To test if that's where it was really getting the icon from, I copied the proper chromium-browser icon into that folder, renamed the tv-guide icon to a.png and renamed the chromium-browser icon to "chrome-http___www.tvguide.com_Listings_.png" which is what the tv-guide icon was called.

Sure enough, I now have all chromium applications showing up as the regular chromium browser icon.

I don't know where to go from here though. Obviously, something told Docky that the tv guide icon was the right one for chromium, but how do I use that?

[Robert Dyer (psybers)]

@Colin: Do a grep in /usr/share/applications and in ~/.local/share/applications for 'tvguide' and you will find a launcher somewhere you created to do a 'web app' version of tv guide. If you delete that launcher it would fix your problem.

[matbonucci (matbonucci)]

thanks #19 it solved my problem

[timvdwest (timvdwest)]

I experienced a similar problem with a Chrome "Coolris" extension that "broke" the feed for the Docky Gmail docklet.

When the Gmail docklet checks mail it receives a feed from Gmail:

[GMailAtom] Fetching Atom feed: https://mail.google.com/mail/feed/atom/Inbox

With the extension disabled it the incoming feed is correct:

Gmail - Label 'inbox' for <email address hidden> New messages in your 'inbox' label 0 2010-11-07T22:00:52Z

When enabling the extension the feed outputs the following:

(function setPicLensContext() { window.PicLensContext = function() { return (function initCooliris(custom_attributes) { var cooliris = document.getElementById('coolirisBridge'); if (!cooliris) { var default_attributes = { type: 'application/x-cooliris-page', hidden: 'true', }; if (navigator.platform.indexOf('Linux') != -1) { // Workaround for http://crbug.com/20474 default_attributes.style = 'width: 1px; height: 1px; position:absolute; left: -10000px'; default_attributes.hidden = 'false'; } var plugin_attributes = custom_attributes || default_attributes; plugin_attributes.id = 'coolirisBridge'; cooliris = document.createElement('embed'); for (var attr_name in plugin_attributes) { cooliris.setAttribute(attr_name, plugin_attributes[attr_name]); } document.documentElement.appendChild(cooliris); if (top == self) { document.addEventListener("mouseover", function (e) { cooliris.onMouseOver(e); }, true); document.addEventListener("mouseout", function (e) { cooliris.onMouseOut(e); }, true); if (chrome.extension) { window.addEventListener("LaunchableChanged", function () { var launchable = (cooliris.getAttribute("launchable") == "true"); chrome.extension.connect({name:"LaunchableChanged"}).postMessage({launchable: launchable}); }, false); } } } return cooliris; })(); }; document.documentElement.removeChild(document.getElementById('coolirisScript')); })(); Gmail - Label 'inbox' for <email address hidden> New messages in your 'inbox' label 0 2010-11-07T22:00:52Z

The docklet can't interpret this and stays greyed out.

[Robert Dyer (psybers)]

@timvdwest:

1) this bug is about Chrome apps, your description has no relation to this bug what-so-ever.

2) your 'bug' is not a bug, the gmail plugin doesn't use any browser to fetch the feed data, and thus *no* browser plugin could possibly cause the feed data it receives to be wrong. Trust me on this.

[shad (shad)]

You can set WM_CLASS on chromium apps with the --class parameter.

As in:
Exec=chromium-browser --app="YOURURL" --class=YOURCLASS

For more than one app you have to launch each one with a unique --user-data-dir parameter. The full Exec line in your *.desktop should be something like this:

Exec=chromium-browser --user-data-dir=/UNIQUE/PATH/1 --app="YOURURL1" --class=YOURCLASS1

Downside:
Chromium seems to ignore xdg-open rules when clicking an external link in an app. For example I use Firefox as my main browser and Chromium for webapps (simply because setting WM_CLASS in Prism/Firefox seems to be broken for a long time now), clicking an external link in my Google Reader app spawns a new Chromium window with its parent WM_CLASS.

[matt.blackwell (mblackwell)]

Just wanted to let you know that the Chromium team is making progress on this bug:

http://code.google.com/p/chromium/issues/detail?id=20587

I have not tested this, but web app launchers should now open a window with a custom WM_CLASS based on the app name instead of "Google Chrome".

[Marco Trevisan (Treviño) (3v1n0)]

Yes, I confirm that the WM_CLASS is now different; however you need to test it using nightly versions of chromium 12 ;)

[Rachel Greenham (rachel-strangenoises)]

It's years later. Let's catch up. :-) I'm using Trusty beta, and chrome 33, and just today I started using Docky because of issues with not being able to move Unity's Launcher and multiple monitors. It's all looking very promising...

I use the TweetDeck webapp. I had already done the thing to create a shortcut in the menu (which puts a .desktop file in ~/.local/share/applications) In Launcher this behaves as you would expect, like a separate application. You can launch it from Dash, lock it to the launcher, it opens a separate window and the launcher icon has a little arrow next to *it* when it's running, and not an extra one on the Chrome icon. etc. etc. In other words, entirely as you'd want, and like it's a standalone application.

With Docky, you have to find the .desktop file and drag it to Docky to add it. That works. But when you click on it, the window opens properly (ie: without browser furniture, tab/tool/bookmark bars etc.) but it's the Chrome icon in Docky that gains an extra light. And other behaviour that basically means, it's still not thinking of it as a separate application but just working as a dumb launcher.

That Chromium bug linked above is marked as Fixed (as of April 2011, a little after the most recent comment here), and as noted, it works in Launcher. ;-) As far as I can scan the fix seems to relate to BAMF, and that was mentioned earlier here. Is Docky not using BAMF yet as of 2.2? It seemed implied to be work in progress 3.5 years ago above. :-}

[Timo Reimerdes (timorei)]

Indeed. This bug is still around. I'm not convinced that this will get fixed without a community patch.

[Philip (j-launchpad-net)]

Hello.

I was facing a similar issue but I appear to have it working on my system. Do note I am using eOS with plank, which I have taken to be a fork of docky.

I had the same issues with my own created .desktop files but I had chrome generate them for me and it worked.

I added the GMail app from the chrome extension store.
Opened a new tab (Using default new tab page)
Clicked apps (Top left)
Right clicked the Gmail icon and selected "Create shortcuts"
De-selected desktop, then selected launchers/menus.

This added it to my menu (Slingshot) and has its own independant icon in the dock.
Chrome created a .desktop file in my ~/.local/share/applications folder.

This is one of them, in case you were interested.

~~~~~
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=Gmail
Exec=/opt/google/chrome/google-chrome --profile-directory=Default --app-id=pjkljhegncpnkpknbcohdijeoejaedia
Icon=chrome-pjkljhegncpnkpknbcohdijeoejaedia-Default
StartupWMClass=crx_pjkljhegncpnkpknbcohdijeoejaedia
~~~~~

I hope this helps you guys, I'm new to the deb OSs coming from rpms, I'm glad my new OS is going smoothly :-D

Cheers Phil.

[Bryan (bryan3)]

Phil, is xprop actually showing the the WMClass as crx_pjkljhegncpnkpknbcohdijeoejaedia? I ask because I'm on Ubuntu Trusty, using the same methodology on Docky 2.2, but I still get incorrect categorization. The window launches, but is associated with the main chrome launcher.

Interestingly, the sub-icon is correct though...

[JuHwon (juer-wagner)]

Same here. I can start it, though the launched window associates with the chrome launcher.