BAMF window matching for Chromium webapps

Bug #744972 reported by Jorge Castro on 2011-03-29
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Marco Trevisan (Treviño)
Fix Released
bamf (Ubuntu)
unity (Ubuntu)

Bug Description

(On behalf of didrocks),

Chromium webapps regressed with the move to Compiz, that is there's no way to easily add web shortcuts to the launcher, this was made more difficult that we couldn't really match windows well in Chromium.

Upstream fixed a bug while testing for Unity to make it so we can classify their windows better, this is the fix to BAMF so webapps show up as webapps instead of another browser window.

Original bug report:

Related branches

Jorge Castro (jorge) on 2011-03-29
description: updated

This sounds like a bug fix to resolve a regression, not a new feature. Am I
missing something?

Martin Pitt (pitti) wrote :

I concur; removing FFE flag and adding regression tag.

summary: - BAMF window matching for Chromium webapps FFe
+ BAMF window matching for Chromium webapps
tags: added: natty regression-release
Changed in bamf:
status: New → Fix Released
assignee: nobody → Treviño (Marco Trevisan) (3v1n0)
Didier Roche (didrocks) on 2011-04-05
Changed in unity:
status: New → Fix Released
Bill Filler (bfiller) wrote :

Reopening this bug as it's not working correctly when you have mulitple chrome web apps in the launcher. The second launcher webapps is always matched even when launching the first webapp.

using chromium-browser 10.0.648.204~r79063-0ubuntu2
bamf 0.2.82-0ubuntu1

Steps to reproduce:
1) open chromium browser
2) go to website 1
3) click on wrench->tools->Create Application Shortcut..., Choose "save to desktop"
4) go to website 2
5) click on wrench->tools->Create Application Shortcut..., Choose "save to desktop"
6) drag each webapp from the desktop to the launcher
7) launcher webapp 1 from launcher and notice webapp2 is matched and shown as running

Expected result:
proper webapp that is running should be matched.

Changed in bamf:
status: Fix Released → Confirmed
Jorge Castro (jorge) on 2011-04-06
Changed in bamf (Ubuntu):
status: New → Confirmed
Fabien Tassin (fta) wrote :

on the Chromium side, there's still a part missing.
Chromium trunk and dev are now exposing a dedicated class per webapp, but they are not generating the matching StartupWMClass in the desktop files, yet. Action still pending upstream.

As i said in the other bug, i will backport those two parts to stable once it's been verified as working in trunk.

Fabien that bug has been fixed:

I still should investigate if the new issue is related to chromium or unity... I'll look to this on next days.

Didier Roche (didrocks) on 2011-04-07
Changed in bamf:
status: Confirmed → Fix Released
Fabien Tassin (fta) wrote :

ok, I tried with a post r80656 snapshot. The desktop file now has its own StartupWMClass.

I tried with

I got StartupWMClass=mysqueezebox.com__player_playerControl

but once running, xprop shows:

WM_CLASS(STRING) = "mysqueezebox.com__player_playerControl", "Chromium-browser"

and unity is still totally confused, my main browser and all my other chromium webapps highlight this squeezebox launcher.

The main browser still shows:

WM_CLASS(STRING) = "chromium-browser", "Chromium-browser"

Fabien Tassin (fta) wrote :

hmm... it seems better once the bamf.index is rebuilt (after something unrelated is installed and triggered the bamfdaemon hooks).

Does this mean webapps can't work immediately on unity? it will sure create confusion for end users..

Fabien Tassin (fta) wrote :

n-m my last comment, it doesn't work at all.

Fabien Tassin (fta) wrote :

What if the .desktop for the webapp is created in ~/.local/share/applications where there is no index? That should "just work"..?

In that case the desktop file is loaded, but just only after BAMF has been reloaded. Another thing that BAMF should do is monitoring applications dir for changes. I planned that, but I'm so busy right now. :(
I hope to look at this on next days.

Never mind... BAMF needed a reload since it was bad scanning the directory for new files (and before my previous merge, it wasn't either scanning that local dir, due to a typo)... I'll push a fix to that soon.

However, finally I looked to this. Chromium still needs a fix for this to work (it's just a one-line patch to invert the parameters to gtk_window_setwmclass), see:

Didier Roche (didrocks) on 2011-05-31
Changed in unity-2d:
status: New → Fix Released
Jason Smith (jassmith) wrote :

This is really fixed now :/ Seems we regressed at some point

Changed in unity (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.