unity confused with chrome/chromium web apps

[Fabien Tassin]

SRU testcase

1. start chromium-browser
2. create a webapp for twitter.com
3. drag it to launcher while chromium is already running
4. click its icon you will see twitter.com is opened in a new window but is still associated with chromium icon
5. now install Bamf from precise-proposed
6. note that twitter window is associated to the newly dropped icon in the launcher.

On my classic desktop panel, i have 2 webapps launchers in the gnome-panel.
Basically, they are just "chromium-browser --app=http://some.web.site --some-other-flags ..." + a nice icon
Chromium is my default browser.
In the new unity based desktop mode, those webapps now appear nicely.

The problem is that when i start my default web browser, unity highlights on the left one of my webapp launchers, instead of creating one for the browser itself.

And worse.. once the browser is running, i can't start this webapp anymore as unity keeps raising the main browser instead.
For the other webapp, it works as expected.

ii libunity-misc0 0.1.1-0ubuntu3 Miscellaneous functions for Unity - shared library
ii libunity0 0.2.46-0ubuntu5 binding to get places into the launcher - shared library
ii libunity3 3.2.8-0ubuntu1 binding to get places into the launcher - shared library
ii unity 3.2.8-0ubuntu1 Interface for Ubuntu Desktop Edition
ii unity-asset-pool 0.8.18-0ubuntu2 Unity Assets Pool
ii unity-common 3.2.8-0ubuntu1 Common files for the interface for Ubuntu Desktop Edition
ii unity-place-applications 0.2.26-0ubuntu2 Application place for unity
ii unity-place-files 0.5.32-0ubuntu1 File place for unity

=========================================================================

This bug would be an ideal bug for someone to get started hacking on Unity, here's some information:

 * Time to fix: unknown but large
 * Difficulty: brutal
 * Implementation:

This is a complex issue to solve correctly. The most correct implementation associates URI's with windows inside of bamf. Such that bamf's exported tree becomes BamfApplication -> BamfWindow ->BamfUri (currently called BamfTab and incomplete in source).

To achieve this goal there are three primary components. The first is a BamfUriSource. This source is a class used by an application to export its known URI's over dbus to BAMF. The implementation details are not that important, however it is important that it be trackable (so if it crashes we can eliminate references to it) and that it provide two way communication. In short, it needs to tell the bamf daemon about all the uri's it has, and the bamf daemon needs to in turn be able to ask a bamf uri source to "show" a specific uri in its window.

Bamf Daemon will then convert the BamfUriSource into many BamfUri's for exporting over the bus. A bamf uri should look something like and inherit from BamfView:

char * bamf_uri_get_uri (BamfUri *self)
char * bamf_uri_get_icon (BamfUri *self)
char * bamf_uri_get_title (BamfUri *self)
void bamf_uri_show (BamfUri *self)

In short: that part sucks

The second part is making web browsers export tab uri information over dbus using BamfUriSource. This should be somewhat simple if you know the browser plugin API's using a standard NPAPI plugin. The C potion of the plugin can consume bamf and pass data along, while the javascript can communicate with the browser to get relevant information about the state of the system.

The third and final task is to hook this all into unity. This is relatively straightforward to do. By making a launcher shortcut that points to a uri rather than an application, unity can associate an BamfUri with it, watching when it opens and closes. When clicked, unity can call bamf_uri_show () on the proper uri, which will result in the window raising itself and flipping to the appropriate tab. Excellent.

The most clarifying thing I can think to say here is that when you call bamf_uri_show, what should happen is libbamf will call Show on the correct dbus object that was exported by bamfdaemon. Bamfdaemon will then find the associated BamfUriSource for that BamfUri object, can call show back on it, passing along the id of the uri it wishes to have shown. The NPAPI plugin will receive this call, and pass the information up to the javascript layer, which should then raise the window and switch tabs. Like a boss.

 * Where to look: lp:bamf and lp:unity are the primary consumers.

   -lp:bamf requires the most work. BamfTabSource and BamfTab need to be converted, exported, and consumed in libbamf
   -lp:unity would simply consume the newly exported information

 * Workflow information: http://unity.ubuntu.com/getinvolved/

[Steve Baker (steve-stevebaker)]

This also affects Docky. The proper place to fix this is Chromium. Here is the related Chromium issue:
http://code.google.com/p/chromium/issues/detail?id=42587

[David Barth (dbarth)]

Thanks for the pointer Steve.

And to confirm, there is indeed a problem upstream in that bamf can't tell the difference between two instances. Having a fix like described in the bug would help immensely.

[David Barth (dbarth)]

I'm leaving the Unity side of the bug open as a whishlist item to avoid getting more duplicates in the future. It is an important issue though, and one we definitely want to solve next cycle.

[Steve Baker (steve-stevebaker)]

Can someone provide the Chromium devs some indication that this patch does the right thing?
http://code.google.com/p/chromium/issues/detail?id=20587#c26

[Jorge O. Castro (jorge)]

Hi Steve,

Just got a mail from Evan asking for input and I've asked Neil to look at it.

Now we just need to fix this in BAMF, now that we have the WMCLASS

[Jorge O. Castro (jorge)]

Marco,

Any luck with this? Let me know if you need help, Jason can help point you in the right direction.

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

Sorry, I had no time to look at it yet (I just checked that the nightly version of chromium was fixed)... I'm doing it right now ;)

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

Well, I'm looking the best way to implement it... In the current implementation bamf always tries to associate each window to its application, and since a chromium app and a chromium instance shares the same pid they are considered as the same application.

Now, using the window class, it's possible to be more accurate, but what is the preferred behavior?
I was thinking to just associate the window class to match to each application (or to a view); so when a new window is going to be matched, if it has not the same window class of a "matching application in the current implementation", it's considered as a new application.
However this would cause that if two windows with different class will be ALWAYS considered as two different applications. This is good for me, but I don't know if there are situations where this could be considered as a bad thing (since it's a stronger discriminant than the ones currently used).

PS: By the way to get this bug fixed in natty, chromium should be updated too. Versions before the recent nightlies of chromium 12 won't work!

[Fabien Tassin (fta)]

Natty will most probably have chromium 11, but if you can make it work for the current daily, i'll backport the relevant bits before release.

anyway. In my case, my webapps don't share the same pid because i give each webapp its own --user-data-dir (but it's probably only me).

I see in the desktop file of a regularly created webapp that it has "StartupWMClass=Chromium-browser", is that a problem for bamf? xprop shows the expected WM_CLASS though.. but it works only when the webapp is running, so i don't know how unity is supposed to know when to start a new instance or raise the existing one.

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

Cool tip Fabien... That StartupWMClass helps me a lot to check if I can use a selected desktop file as the app desktop. It's important not to confuse the chromium main desktop file with the application one and vice-versa (since, thanks God, is defined in the main chromium desktop too :P)...

[Fabien Tassin (fta)]

just to be sure we understand the same thing: both desktop files have the exact same StartupWMClass.
Only xprop is different, but apps have to be running so i don't know how you can do the right thing unless each desktop file has its own distinct StartupWMClass. But i know nothing about bamf, so i may be wrong.

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

Oh, Damn... I misunderstood what you meant. Yes: this is a problem.
I mean, not so much for making the default chromium instance to be seen as a different application compared to the launched apps, but just to associate to the chromium apps their real desktop file (and icons then). They will use their xwindow icon and details so.

I guess we should patch chromium again to support the saving of the correct desktop file when generating it for an app. I've wrote a comment in the related bug issue ( http://code.google.com/p/chromium/issues/detail?id=20587#c33 ) but maybe we need to open a new issue, since that is now fixed.

In the case, that no one from upstream will move I could provide one to be backported to chromium available in Ubuntu, also if right now I'm just a little bit lazy to compile it :P

[Fabien Tassin (fta)]

what chromium does atm is just to find the browser desktop file, and use it as template for its webapps, by doing:
- "Exec=" => updated to run the browser with the --app= flag
- "Name=" => updated to match the webapp title
- "GenericName", "Comment", "#" => dropped
- "MimeType=" => dropped
- "Icon=" => updated to use the site's favicon
- everything else => copied vanilla.

So one more rule could be added to also update StartupWMClass and assign it the same value as the runtime WM_CLASS

[Fabien Tassin (fta)]

that's in chrome/browser/shell_integration_linux.cc: ShellIntegration::GetDesktopFileContents()

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

Yes that should be done. I'll give a look.

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

Ok the bug, from the BAMF side should be now fixed (see lp:~3v1n0/bamf/wmclass-matching ).

To fix completely it in chromium an app StartupWMClass should match its xwindow WMCLASS.

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

This is not related too much whit this bug, but I was thinking that BAMF maybe should take care also of the .desktop files in ~/Desktop folder and not only the ones in the default "applications" folders. This would allow to define short-cuts in desktop and use them as desktop files associated with a BAMF application (with an icon and so)...
Maybe it's not standard, but reasonable.

If it can be considered, I could open a bug / branch.

[Fabien Tassin (fta)]

Just backported the chromium part from trunk to the stable branch.
It's committed in my branch for Natty, and I've also updated the -stable PPA (it's currently building as 10.0.648.204~r79063-0ubuntu3~ucd~stable1). Please test before I release to natty.

ppa:chromium-daily/stable

[Jorge O. Castro (jorge)]

Ok creating a .desktop app with this build results with:

StartupWMClass=mail.google.com__mail_u_0

in a gmail shortcut, and xprop | grep CLASS returs:

WM_CLASS(STRING) = "mail.google.com__mail_u_0", "Chromium-browser"

So it looks like that part's all set.

[Launchpad Janitor (janitor)]

This bug was fixed in the package chromium-browser - 10.0.648.205~r81283-0ubuntu1

---------------
chromium-browser (10.0.648.205~r81283-0ubuntu1) natty; urgency=high

  * New upstream minor release from the Stable Channel (LP: #762275)
    This release fixes the following security issues:
    - [75629] Critical, CVE-2011-1301: Use-after-free in the GPU process.
      Credit to Google Chrome Security Team (Inferno).
    - [78524] Critical, CVE-2011-1302: Heap overflow in the GPU process. Credit
      to Christoph Diehl.
  * Make the default mail client and browser settings work with the
    x-scheme-handler method of registering URI handlers in gnome3.
    This is based on the xdg-utils 1.1.0~rc1-2ubuntu3 fix by Chris Coulson
    <email address hidden>, itself based on Bastien Nocera <email address hidden>
    upstream fix (LP: #670128)
    - add debian/patches/xdg-utils_gnome3_lp670128_for_natty.patch
    - update debian/patches/series
  * Fix the apport hooks to pass the expected 'ui' to add_info(), needed when
    called from apport/ubuntu-bug (LP: #759635)
    - update debian/apport/chromium-browser.py
  * Report a dedicated WMClass per webapp, needed by Unity/bamf.
    (backported from trunk) (LP: #692462)
    - add debian/patches/webapps-wm-class-lp692462.patch
    - update debian/patches/series
 -- Fabien Tassin <email address hidden> Thu, 14 Apr 2011 22:36:16 +0200

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

As I suspected this is wrong. It should be instead:
 WM_CLASS(STRING) = "chromium-browser", "mail.google.com__mail_u_0"

Chromium must be fixed, it's just a one-line patch to invert the parameters to gtk_window_setwmclass, we should fix this in ubuntu quickly if chromium won't do it.
Read more at: http://code.google.com/p/chromium/issues/detail?id=20587#c50

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

The bug in chromium should be now finally fixed. Please, Fabien backport the new fix in chromium too.

[Launchpad Janitor (janitor)]

This bug was fixed in the package chromium-browser - 11.0.696.57~r82915-0ubuntu0.11.04.1

---------------
chromium-browser (11.0.696.57~r82915-0ubuntu0.11.04.1) natty-security; urgency=high

  * New Major upstream release from the Stable Channel (LP: #771935)
    This release fixes the following security issues:
    + WebKit issues:
      - [61502] High, CVE-2011-1303: Stale pointer in floating object handling.
        Credit to Scott Hess of the Chromium development community and Martin
        Barbella.
      - [70538] Low, CVE-2011-1304: Pop-up block bypass via plug-ins. Credit to
        Chamal De Silva.
      - [70589] Medium, CVE-2011-1305: Linked-list race in database handling.
        Credit to Kostya Serebryany of the Chromium development community.
      - [73526] High, CVE-2011-1437: Integer overflows in float rendering.
        Credit to miaubiz.
      - [74653] High, CVE-2011-1438: Same origin policy violation with blobs.
        Credit to kuzzcc.
      - [75186] High, CVE-2011-1440: Use-after-free with <ruby> tag and CSS.
        Credit to Jose A. Vazquez.
      - [75347] High, CVE-2011-1441: Bad cast with floating select lists.
        Credit to Michael Griffiths.
      - [75801] High, CVE-2011-1442: Corrupt node trees with mutation events.
        Credit to Sergey Glazunov and wushi of team 509.
      - [76001] High, CVE-2011-1443: Stale pointers in layering code. Credit to
        Martin Barbella.
      - [76646] Medium, CVE-2011-1445: Out-of-bounds read in SVG. Credit to
        wushi of team509.
      - [76666] [77507] [78031] High, CVE-2011-1446: Possible URL bar spoofs
        with navigation errors and interrupted loads. Credit to kuzzcc.
      - [76966] High, CVE-2011-1447: Stale pointer in drop-down list handling.
        Credit to miaubiz.
      - [77130] High, CVE-2011-1448: Stale pointer in height calculations.
        Credit to wushi of team509.
      - [77346] High, CVE-2011-1449: Use-after-free in WebSockets. Credit to
        Marek Majkowski.
      - [77463] High, CVE-2011-1451: Dangling pointers in DOM id map. Credit to
        Sergey Glazunov.
      - [79199] High, CVE-2011-1454: Use-after-free in DOM id handling. Credit
        to Sergey Glazunov.
    + Chromium issues:
      - [71586] Medium, CVE-2011-1434: Lack of thread safety in MIME handling.
        Credit to Aki Helin.
      - [72523] Medium, CVE-2011-1435: Bad extension with ‘tabs’ permission can
        capture local files. Credit to Cole Snodgrass.
      - [72910] Low, CVE-2011-1436: Possible browser crash due to bad
        interaction with X. Credit to miaubiz.
      - [76542] High, CVE-2011-1444: Race condition in sandbox launcher. Credit
        to Dan Rosenberg.
      - [77349] Low, CVE-2011-1450: Dangling pointers in file dialogs. Credit
        to kuzzcc.
      - [77786] Medium, CVE-2011-1452: URL bar spoof with redirect and manual
        reload. Credit to Jordi Chancel.
      - [74763] High, CVE-2011-1439: Prevent interference between renderer
        processes. Credit to Julien Tinnes of the Google Security Team.
  * Fix the password store regression from the last Chromium 10 update.
    Backport from trunk provided by Elliot Glaysher from...

[centy (jacek-nowosielski)]

I have tested it little bit and it is not working for me.
Try to open chromium and Gmail app. Then try to check :
xprop | grep _NET_WM_DESKTOP_FILE on both
Result is:
_NET_WM_DESKTOP_FILE(STRING) = "/usr/share/applications/chromium-browser.desktop"
for both.
This confuses BAMF in fucntion bamf_matcher_possible_applications_for_window in file bamf-matcher.c.

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

Yes, we know. My fix was overriding this when the WM_CLASS was different, but it was reverted after some time.
I contacted Jorge Castro who said me that we'll look to that at UDS...

[Evan Martin (Chromium) (evan-chromium)]

I am confused by the updated description. Is the WM_CLASS we set not enough?

[David Barth (dbarth)]

I think the new description is out of scope for this bug. The scope of this issue is that desktop files using the --app mode of chromium should be able to be differentiated from the other chromium instances, which the WMCLASS flag should solve.

The more general problem of matching any site or application running in a browser window or tab is another problem, and requires it's own separate bug to track the task.

I recommend to stay focused on the specifc --app problem for now, as I can still confirm the issue here, running standard unity on natty, and the latest daily build of chromium.

[Jason Smith (jassmith)]

@Evan : It's sufficient to deal with --app mode only. It won't allow for more complex interactions with web apps. If a user already has a tab open in a browser mode chromium this will not be reflected back to the user.

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

The --app parameter is now correctly related to the WM_CLASS, the issue is in BAMF that doesn't discern for different applications. My old fix was merged, but it was not considering some cases which lead BMAF to a crash (so it was reverted).

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

Give a look to this comment: https://bugs.launchpad.net/bamf/+bug/702452/comments/8

There are some things related to this bug too. And mostly the libwnck bug which doesn't allow us to get the proper WM_CLASS resource name (but just the class name itself) [1].
Due to that bug, I also made chromium badly implement the ICCCM standard, asking them to switch the res_name and the class_name (sorry, but it was the only way to get the relevant value using libwnck).

[1] https://bugzilla.gnome.org/show_bug.cgi?id=168718

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

Ok, before of working again in BAMF to get this fixed for good, I guess that we need another little bit effort from the chromium side: http://code.google.com/p/chromium/issues/detail?id=20587#c64 :P

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

The chromium patch we need has been merged: http://src.chromium.org/viewvc/chrome?view=rev&revision=95492

Please include it in our chromium packages, I hope to work on the BAMF fix as soon as I can, also if I don't know if I'll be able to commit it before the freeze of this cycle (damn, now it's holidays time! :P)...

[Didier Roche (didrocks)]

I fix is needed for chromium, the new bamf only works with chrome atm.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bamf - 0.2.100-0ubuntu1

---------------
bamf (0.2.100-0ubuntu1) oneiric; urgency=low

  * New upstream release.
    - Fix unity confused with chrome web apps (LP: #692462)
 -- Didier Roche <email address hidden> Thu, 22 Sep 2011 15:15:28 +0200

[Jorge O. Castro (jorge)]

Sorry, not quite fixed yet.

If you create a new application shortcut from the things installed on the chrome store the window matching works, but if you create one out side the store it still mixes it up with the web browser window, even if you close it and relaunch the web app again.

To reproduce, on this webpage:

Wrench->Tools->Create Application Shortcuts ...

Then select Desktop or application check boxes (either or or both will work), then click ok. It creates the shortcut but the new webapp is still matched as a Chrome window. If you close it and then launch it from the new launcher you just created the same thing happens.

[Jorge O. Castro (jorge)]

Attaching .desktop file made in this manner as instructed:

[Jorge O. Castro (jorge)]

Here's the xprop as instructed:

_COMPIZ_WINDOW_DECOR_INPUT_FRAME(WINDOW): window id # 0x1200464
_COMPIZ_WM_WINDOW_BLUR_DECOR(INTEGER) = 4, 0, 5, 4, -29, 6, -4, -28, 5, 2, -28, 6, -2, -27, 5, 1, -27, 6, -1, -26, 5, 0, -26, 6, 0, -24, 5, -1, -24, 6, 1, 0, 9, -1, 0, 10, 1, 1, 5, -1, 0, 9, 0, 0, 6, 0, 0, 10, 1, 0
_COMPIZ_WINDOW_DECOR(INTEGER) = 20110504, 1, 58732134, 8, 8, 29, 8, 1, 1, 29, 1, 0, 0, 29, 0, 0, 0, 29, 0, 26, 0, 589925, -8, -33, -6, 0, 946, 32767, 0, 0, 524389, 938, -33, -6, 0, 32767, 32767, 946, 0, 590182, -6, -33, 10, 0, 16, 32767, 963, 0, 395413, -8, 0, 0, -577, 32767, 578, 1, 35, 264341, -8, 578, 0, -577, 32767, 32767, 579, 35, 395929, -8, -577, 0, 0, 32767, 577, 1157, 35, 395430, 0, 0, 10, -577, 32767, 578, 1, 45, 264358, 0, 578, 10, -577, 32767, 32767, 579, 45, 395946, 0, -577, 10, 0, 32767, 577, 1157, 45, 589993, -8, 0, -472, 13, 480, 32767, 0, 57, 524457, 472, 0, -472, 13, 32767, 32767, 480, 57, 590250, -472, 0, 10, 13, 482, 32767, 963, 57
_NET_WM_ICON_GEOMETRY(CARDINAL) = 9, 244, 48, 48
XKLAVIER_STATE(INTEGER) = 0, 0
WM_STATE(WM_STATE):
  window state: Normal
  icon window: 0x0
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x1, 0x0, 0x0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_STATE(ATOM) =
_NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 29, 1
WM_HINTS(WM_HINTS):
  Client accepts input or input focus: True
  Initial state is Normal State.
  bitmap id # to use for icon: 0x2812179
  bitmap id # of mask for icon: 0x281217a
  window id # of group leader: 0x2800001
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
_NET_WM_ICON(CARDINAL) = Icon (16 x 16):

     ░
     ░
     ░
     ░ ░ ░░
     ░ ░ ░
     ░ ░ ░
     ░ ░
     ░ ░ ░
     ░ ░ ░
     ░░ ░
         ░
         ░

WM_WINDOW_ROLE(STRING) = "bugs.launchpad.net__bamf_+bug_692462"
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 42016999
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME(CARDINAL) = 487167264
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x28120e6
WM_CLIENT_LEADER(WINDOW): window id # 0x2800001
_NET_WM_PID(CARDINAL) = 7035
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "lowgirl"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
  program specified minimum size: 1 by 1
  window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "google-chrome", "bugs.launchpad.net__bamf_+bug_692462"
WM_ICON_NAME(COMPOUND_TEXT) = "Bug #692462 in BAMF: “unity confused with chromium web apps”"
_NET_WM_ICON_NAME(UTF8_STRING) = "Bug #692462 in BAMF: “unity confused with chromium web apps”"
WM_NAME(COMPOUND_TEXT) = "Bu...

[Jason Smith (jassmith)]

Okay found and fixed the issue

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jason Smith (jassmith)]

The fix is in trunk of bamf, stop un-fixing the bug

[Launchpad Janitor (janitor)]

This bug was fixed in the package bamf - 0.2.104-0ubuntu1

---------------
bamf (0.2.104-0ubuntu1) oneiric; urgency=low

  * New upstream release.
    - Hopefully really fix unity confused with chrome (not chromium) web apps
      (LP: #692462)
    - Fix to build with gtk2 version
 -- Didier Roche <email address hidden> Mon, 26 Sep 2011 13:51:22 +0200

[phillamg (me-phillg)]

Has this bug re-appeared? Since this week's update (to Chrome 15 as stable, unity 4.24 from -proposed) web apps in Chrome are no longer separate. I've deleted all custom launchers and re-added shortcuts cleanly through Chrome. See screenshot

[Tom (tlinsky)]

It has reappeared for me too. Well, it never really was completely fixed to begin with. Prior to this week, the bug seemed fixed for one web app but with more then one, unity was still confused and grouped all of them under the same icon.

[Filipe Aguiar (filipe-aguiar-cavalcanti)]

In the default Unity Shell, it never worked. But in Unity 2D it used to work
flawlesly. But now it's all messed up again.

2011/10/28 Tom <email address hidden>

> It has reappeared for me too. Well, it never really was completely
> fixed to begin with. Prior to this week, the bug seemed fixed for one
> web app but with more then one, unity was still confused and grouped all
> of them under the same icon.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/692462
>
> Title:
> unity confused with chromium web apps
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/bamf/+bug/692462/+subscriptions
>

[Jose (joserobleda)]

Same problem here. I have this problem in my laptop when updated to chrome 15. In my desktop pc I stay in chrome 14 and unity works as expected

I think the fastest way to "solve" the problem is downgrading chrome if possible.

[Jeremy (jeremyafrank)]

I have the latest Chromium, same problem

[Jeremy (jeremyafrank)]

What's worse:

[Desktop Entry]
Version=4.0
Type=Application
Terminal=false
Icon[en_US]=/usr/share/icons/theme/128x128/apps/gmail.png
Name[en_US]=Gmail
Exec=/usr/bin/chromium-browser --user-data-dir=/home/REDACTED/.webapps/gmail/ --app=http://www.gmail.com
Name=Gmail
Icon=/usr/share/icons/theme/128x128/apps/gmail.png
StartupWMClass=mail.google.com,Chromium-browser

works like a charm when I double click it, but any attempt to run the same command (or try that long trick involving `grep '^Exec' $1 | sed 's/^Exec=//' | sed 's/%.//'` & to run a .desktop from the command line) will have it come up as another browser window

[Marcantonio (marcantonio)]

This worked perfectly for me in the default Unity shell with Chrome 14. Updating to Chrome 15 broke it.

[phillamg (me-phillg)]

Is this bug going to be re-opened then? Fix-released is not an accurate status any more...

[scottku (scottku)]

Trevi55 in chromium issue #20587 indicated that this is a problem in BAMF in Ubuntu, so this bug should probably be reopened as affecting that project.

[Didier Roche (didrocks)]

It's a regression, putting it in the SRU list and unity distro priority list

[Omer Akram (om26er)]

this bug was never fixed, neither for chrome nor for chromium.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

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

The bug itself is in BAMF, so please set its status back to confirmed.

Also, I've to say that the but had been fixed using the chromium-browser available in the oneiric/universe repositories (version 14.0.835.202~r103287-0ubuntu1), but it had not for recent chromium (like the 15.0.874.106~r107270-0ubuntu0.11.10.1 version that is in oneiric-proposed).

So, to fix this issue we basically need:
 1) Move to Chromium 15
 2) Work on BAMF (I can do this)

[Vlad (vcosvic)]

I'm on chromium 17 and the problem stil persists.

[Colin Jia Zheng (jcolinzheng)]

I can confirm that the bug still persists on Chromium 17 and unity (oneiric).

[David Barth (dbarth)]

See also https://bugs.launchpad.net/unity/+bug/939409 which is specific to Chrome and which higlights a clear regression since Oneiric.

[Jorge O. Castro (jorge)]

Marco's branch fixes this for me, I pulled it, built it, logged out and back in. So far this works:

- Clicking on the application icon switches to it (even in multimonitor!)
- Pinning works.
- Alt-tabbing works, each application is also separated into it's own workspace like normal apps.

This does not work:

- Creating a new application shortcut from Chrome still classifies the application as Chrome when it is first created, I have to quit Chrome after creating it and then relaunch the app for it to show up.

I'll bang on this for a few days to see if anything weird happens. Well done!

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

> Creating a new application shortcut from Chrome still classifies the application as Chrome
> when it is first created, I have to quit Chrome after creating it and then relaunch the app for it to show up.

I guess that this is more or less a race: probably chromium creates the new application window too early, when bamfdaemon has not matched the newly created .desktop file yet.
Maybe reducing the filesystem monitor timeout would fix it, but I'd prefer not to do that not to make bamfdaemon to be too aggressive...

[Martin Pitt (pitti)]

Hello Fabien, or anyone else affected,

Accepted unity into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Kevin Mehall (kevin-mehall)]

I updated `unity`, `unity-common`, `unity-services`, and `libunity-core-5.0-5` to version 5.12-0ubuntu1 from precise-proposed, and this bug is still present. The actual change is in the `bamf` source package, which is not updated in proposed.

I built bamf 0.2.116 from source, and that worked.

[Jorge O. Castro (jorge)]

Confirm what Kevin sees, this is a fix in BAMF.

[Corey Kearney (snkiz)]

I'm using unity 2D (shell) I see the same as Kevin.

[Matteo Pagliazzi (paglia)]

the same as kevin... any possibility that bamf 0.2.116 will be avalaible as an update?

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

Yes, it should be released as a SRU as soon as possible...

[Martin Pitt (pitti)]

Matteo Pagliazzi [2012-04-29 17:15 -0000]:
> the same as kevin... any possibility that bamf 0.2.116 will be avalaible
> as an update?

Someone needs to test the -proposed version and confirm that it fixes
the bug and does not introduce a regression.

[Omer Akram (om26er)]

My SRU testcase points at BAMF and not unity so now I removed unity as affects from this bug and will wait for BAMF SRU canidate to get uploaded and accepted.

[Corey Kearney (snkiz)]

@Omer it is true it doesn't work without bamf 0.2.116. I have that and it works, however I just tried a different branch of unity 5.12 and this fix broke. So it isn't all on bamf.

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

Corey, the fix resides only in bamfdaemon... There are some unity and libbamf optimizations that affects even this, but the main fix resides in bamfdaemon itself.

[Charl P. Botha (cpbotha)]

I'd like to add a hopefully useful data point.

I've installed bamfdaemon, libbamf and libbamf3-0 version 0.2.116 from https://launchpad.net/~unity-team/+archive/staging/+packages on an up-to-date 12.04 AMD64 installation.

1. The new bamf indeed solves the problem where I start Chrome, and then application shortcuts. Each application shortcut gets its own icon, and similar app shortcuts are grouped in the Launcher.

2. However, if I start up an application shortcut FIRST, and then Chrome proper, that Chrome is then grouped together with the last started application shortcut icon.

[Charl P. Botha (cpbotha)]

correction: In case #2, Chrome proper is grouped incorrectly with the FIRST started application shortcut icon, not the last.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity - 5.12-0ubuntu1

---------------
unity (5.12-0ubuntu1) precise-proposed; urgency=low

  * New upstream release.
    - Launcher, Alt-Tab - clicking on launcher item or selecting a app in Alt-
      Tab raises all app windows, not just most recently focused (LP: #959339)
    - [heap corruption?] compiz crashed with SIGSEGV in _int_malloc() from
      g_realloc() from ... from g_dbus_connection_send_message_with_reply()
      from g_object_unref() from unity::dash::HomeLens::Impl::~Impl() from
      unity::dash::HomeLens::~HomeLens() (LP: #931201)
    - compiz crashed with SIGSEGV in _int_malloc() from __libc_calloc() from
      XOpenDisplay() from nux::WindowThread::ThreadCtor() (LP: #947844)
    - Regression: Installing apps causes a terrible visual glitch-- have to
      restart X.org. (LP: #981168)
    - Window management - unity doesn't realise when applications bring their
      windows to the front (LP: #802816)
    - Dash - Clicking on the desktop dash border should do nothing, *NOT*
      close the dash (LP: #839472)
    - [FFe, UIFe] HUD - The HUD does not respect launcher icon size settings
      in autohide mode (LP: #921506)
    - compiz crashed with SIGSEGV in g_volume_get_mount() (LP: #918548)
    - multiple instances or double icons of application detected on bamfdaemon
      respawn (LP: #928912)
    - Panel is transparent when Dash is open; no blur no average BG color
      (LP: #965323)
    - Unity crashes with SIGSEGV when hitting debug DBus interface hard
      (LP: #979429)
    - compiz crashed with SIGSEGV in _int_malloc() from g_object_unref() from
      unity::dash::Model<unity::dash::FilterAdaptor>::~Model() (LP: #941750)
    - indicators menu are sometimes cut off at screen edge (LP: #883317)
    - the shortcut keys in workspace section of the shortcut overlay aren't
      translated (LP: #980828)
    - [regression] Dash keeps repainting unnecessarily (LP: #980924)
    - compiz crashed with SIGSEGV in nux::NTextureData::ClearData() from
      nux::NTextureData::~NTextureData() from nux::Texture2D::~Texture2D()
      (LP: #952378)
    - compiz crashed with SIGSEGV in g_object_unref() from
      unity::dash::Settings::~Settings() from
      unity::UnityScreen::~UnityScreen() (LP: #981764)
    - compiz crashed with SIGSEGV in unity::dash::ResultView::~ResultView()
      from unity::dash::ResultViewGrid::~ResultViewGrid() from
      nux::Object::Destroy() from nux::Object::UnReference() (LP: #942286)
    - compiz crashed with SIGSEGV in
      ends_with_iter_select<__gnu_cxx::__normal_iterator<char const*,
      std::basic_string<char> >, char const*, boost::algorithm::is_iequal>()
      from unity::ui::PointerBarrierWrapper::EmitCurrentData() (LP: #983268)
    - Chinese can't be shown completely in dash filter (LP: #984583)
    - [Unity 5.10] compiz crashed with SIGSEGV in
      unity::hud::HudIconTextureSource::ColorForIcon() from
      unity::hud::Icon::Icon() from emit from unity::IconTexture::IconLoaded
      (LP: #983646)
    - [regression] Close button does not close the dash/HUD (LP: #986264)
    - compiz crashed with SIGSEGV in g_volume_eject_with_operation_finish()
      fro...

[Launchpad Janitor (janitor)]

This bug was fixed in the package bamf - 0.2.118-0ubuntu1

---------------
bamf (0.2.118-0ubuntu1) quantal; urgency=low

  [ Didier Roche ]
  * New upstream release. (0.2.116)
    - multiple instances or double icons of application detected on bamfdaemon
      respawn (LP: #928912)
    - unity confused with chrome/chromium web apps (LP: #692462)
    - BamfView's dispose() method doesn't invoke the superclass' dispose()
      (LP: #986888)
  * debian/control:
    - remove Multi-Arch: same for the -dbg package
      (Closes: #669980, #658057)

  [ Alan Pope ]
  * New upstream release.
    - Unity crashed in bamf_application_on_window_removed (LP: #1000577)
    - Locked smuxi launcher icon does not indicate smuxi running status
      (LP: #999820)
    - No launcher icon or Alt+Tab entry for Gimp windows (LP: #995916)
    - the RunningApplicationsChanged signal is no longer emitted when an
      application is closed since r460 (LP: #989551)
 -- Alan Pope <email address hidden> Wed, 23 May 2012 09:10:08 +0100

[Steve Langasek (vorlon)]

Hello Fabien, or anyone else affected,

Accepted bamf into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Launchpad Janitor (janitor)]

This bug was fixed in the package bamf - 0.2.118-0ubuntu0.1

---------------
bamf (0.2.118-0ubuntu0.1) precise-proposed; urgency=low

  [ Didier Roche ]
  * New upstream release. (0.2.116)
    - multiple instances or double icons of application detected on bamfdaemon
      respawn (LP: #928912)
    - unity confused with chrome/chromium web apps (LP: #692462)
    - BamfView's dispose() method doesn't invoke the superclass' dispose()
      (LP: #986888)
  * debian/control:
    - remove Multi-Arch: same for the -dbg package
      (Closes: #669980, #658057)

  [ Alan Pope ]
  * New upstream release.
    - Unity crashed in bamf_application_on_window_removed (LP: #1000577)
    - Locked smuxi launcher icon does not indicate smuxi running status
      (LP: #999820)
    - No launcher icon or Alt+Tab entry for Gimp windows (LP: #995916)
    - the RunningApplicationsChanged signal is no longer emitted when an
      application is closed since r460 (LP: #989551)
 -- Alan Pope <email address hidden> Wed, 23 May 2012 09:10:08 +0100

[Richard Huddleston (rhuddusa)]

for those on the internet that will end up here

i was able to get everything working with google-chrome ... and then locking the app to the bar

--------------------------

#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Application
Exec=/opt/google/chrome/google-chrome --app=http://mail.google.com
Name=Gmail
Comment=Google Mail
Icon=my-gmail-icon.png
Terminal=false
StartupWMClass=mail.google.com

----------------------------------

#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Application
Exec=/opt/google/chrome/google-chrome --app=http://www.pandora.com
Name=Pandora
Icon=my-pandora-icon.png
Terminal=false
Categories=AudioVideo;
StartupWMClass=www.pandora.com

[Collin Peters (collin-peters)]

Richard - does the icon show for you in the Unity panel? It doesn't happen
for me

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.