494586 - Please set WM Class property according to the running WebApp and its .desktop file

Status: RESOLVED WONTFIX

(Mozilla Labs :: Prism, defect)

Description

[Milan Bouchet-Valat]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4pre) Gecko/20090401 Ubuntu/9.04 (jaunty) Shiretoko/3.5b4pre
Build Identifier: 

Prism is setting the WM_CLASS property on its windows very poorly ATM. Here's what I get for any window:
WM_CLASS(STRING) = "Webrunner", "Prism"

In the future GNOME Shell, we use the WM_CLASS to identify apps, and match them with desktop files (thus with icons, commandline, name...). Because of the generic WM_CLASS used by Prism windows, people don't see "Facebook" (e.g.) in the list of often used apps, but "Prism", which breaks the whole idea behind this program! ;-)

I think you could use the two fields to specify both that the window is from the Prism process, and that it's currently running a given WebApp. Normally, the first string should identify the specific application, so here it should be the name of the WebApp; the second string should identify the class of the program, so it could be "Prism" here [1]. ATM, "Webrunner" does not bring any information to us!

The name of the running WebApp should match exactly the name of the .desktop file, installed in the system data dirs (/usr/share/applications/ and friends, see [2]) or in the user data dirs (~/.local/share/applications). Creating a .desktop file on the desktop isn't sufficient for any program to retrieve it: rather, the .desktop file should be created in the user data dir, and a symlink on the desktop should be created (or the contrary if you want the user to be able to remove the app easily).

Apparently, sometimes Prism also creates .desktop files in the user data dir, but adds random numbers after the name of the app (e.g. "Google-15356.desktop"), which completely breaks the design.

I'm open to discussion and investigation if there are problems with this. I know the association between windows and applications as identified by their .desktop files is really broken ATM in free desktops. Solving this should really be a common goal, so that Prism perfectly integrates into the GNOME desktop - anyway, we'll need to create/adapt rules in GNOME Shell so that it handles Prism's case specifically. Thanks for your work!


(BTW, WM_ROLE=main could be improved too by using a unique string for every instance of a WebApp. But that's another story!)

1: http://blogs.gnome.org/metacity/2008/11/02/window-matching/
2: http://standards.freedesktop.org/basedir-spec/latest/

Reproducible: Always

Comment 1

[reikred]

This problem is tripping me up as well. WM_CLASS is important, guys! 

I have previously filed a related bug that --class command line option is not working in mozilla 3 and mozilla 4, but used to work before in mozilla 2.

https://bugzilla.mozilla.org/show_bug.cgi?id=496653

If at least we could get the .desktop file to affect WM_CLASS at least there would be some progress.

Comment 2

[Michael Monreal [:micmon]]

This would be great for GNOME 3.x where currently the window management is horribly broken if two apps (read: two Firefox builds from different channels) run side by side. The WM_CLASS is the same so there can only be one .desktop file

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Prism isn't maintained anymore. Mass closing of the bugs.