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

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Window class for web apps should be different from browser window (need StartupWMClass in generated .desktop entries)
Reported by beg1...@gmail.com, Aug 29 2009 Back to list
Chrome Version       : Any
OS + version : Linux
CPU architecture (32-bit / 64-bit): Any
window manager : Any

What steps will reproduce the problem?
1. Launch a web site in app mode (such as "chromium-browser --
app=http://www.gmail.com")

What is the expected result?
Each web app should be distinguishable by the Window Manager, probably by by 
having their own window class.
These classes would be used in .desktop files as the value for 
StartupWMClass

What happens instead?
Web apps look like just additional browser windows by most window managers, 
for example they will be grouped together with the browser on any type of 
panel/dock which groups application windows.


The window class could be based on the domain of the web app or something 
(like chromium-app-gmail).

Or, a simple command line option could be used in shortcuts such as 
"chromium-browser --app=http://gmail.com --windowclass=Gmail"

 
Comment 1 by beg1...@gmail.com, Aug 29 2009
"--class" is the standard command line option for setting a GTK apps class, but it 
does not work on Chromium
Comment 2 by est...@chromium.org, Aug 31 2009
Status: Available
good call, thanks
Comment 3 by tony@chromium.org, Sep 1 2009
Status: Started
Hmm, maybe we should just set the window class to be based on the -app flag.
Comment 4 by tony@chromium.org, Sep 1 2009
Status: Unconfirmed
Hmm, --class seems to work for me.  Both --class=foo and --class foo show the 
WM_CLASS(STRING)= "chrome", "foo" when using xprop.

That said, it's done on a per application level, so if you already have chrome 
running when you run with --app, it shares the existing process so it doesn't get the 
new --class value.

I guess we could try to change the WM_CLASS instance string, but I think it might 
make sense to use the WM_WINDOW_ROLE instead.  Window managers like ion3 can take 
advantage of the role to position windows.
Comment 5 by beg1...@gmail.com, Sep 1 2009
Right, I had only tried the --class option when it was already running.  The issue is 
making the app have a different class then regular browser windows.

I think the WM_CLASS should be used as it can then be used properly in .desktop 
shortcuts to web apps (StartupWMClass), and many panels and docks already group 
applications based on their WM_CLASS.

Comment 6 by tony@chromium.org, Sep 1 2009
For now, you can work around this by having your app mode windows use a different 
profile using --user-data-dir.
Comment 7 by derat@chromium.org, Sep 1 2009
I am all for using whichever method is most-supported by window managers. :-P

http://www.mail-archive.com/fvwm-workers@fvwm.org/msg01549.html is a message from an 
FVWM developer stating that Pidgin is wrong to use WM_WINDOW_ROLE for anything beyond 
distinguishing between the different roles that windows within a particular instance of 
an app can take.  The Pidgin wiki page referred to in that message doesn't appear to 
exist, so I don't know the Pidgin authors' reasoning or what exactly they were doing.

Setting WM_CLASS to something like ("chrome", "gmail-com") doesn't seem appropriate 
either, at least with a literal reading of the ICCCM 
(http://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS), which states that the second 
string in WM_CLASS "names the general class of applications to which the client that 
owns this window belongs".  Maybe something like ("google-chrome-app-gmail-com", 
"Google-chrome") would make sense, though.

(Sorry, I don't have enough experience with the history of this to know what various 
window managers expect to see in these properties.)
Comment 8 by beg1...@gmail.com, Sep 2 2009
I agree with derat, I think the proper setting is to keep Google-chrome/Chromium-
browser as the second string and base the first one on the app name or domain.  That 
is what the spec seems to encourage, as it is a "particular instance" of the browser, 
I would say.
Comment 9 by evan@chromium.org, Sep 3 2009
Labels: Polish
Status: Available
I just wanted to note that using the "--using-data-dir" workaround is slightly 
problematic. Typical use (for me, at least) of the gmail webapp is to take care of 
all gmail related business. When I click on an external link in the gmail webapp, it 
leads to a new window based on the webapp's user-dir, not the main user-dir, which is 
what I would want. I believe prism has some sort of behavior like this, based on a 
user-specified link-matching. I assume that this is a rather deep issue, but I 
thought I would put it out there. 

If it helps, I am using "Docky" as a dock and I would like my webapp launcher to 
control the webapp window while the chromium launcher to control other instances of 
chromium. That is, I am trying to get them to work more like desktop applications. 
Thanks for any work on this. 
Comment 11 by akaru...@gmail.com, Mar 29 2010
Just curious, don't links on pdf when opened from Adobe reader open in browser windows? 
I feel opening links in browser and transferring the control to the browser feels 
right, may be I am spoilt by Adobe's pdf viewer ;)

Well not quite, I can't remember any desktop app that doesn't transfer you to the 
browser when you click on a link
With X programs (like xterm), you can pass a --name switch to set the first entry in 
the WM_CLASS. I suppose that a fix to this bug could allow for this switch (which 
would work like the --class switch, I suppose). Then, both of these could be at the 
window-level. Also, I just wanted to pass along some functions that might be helpful 
for this bug:

http://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-class.html

I am trying to find where WM_CLASS is set in the source and how you would change it 
for a new window. 
Sorry if this is not helpful, but I think that this could be implemented by adding a 
call to this function:

http://library.gnome.org/devel/gtk/2.15/GtkWindow.html#gtk-window-set-wmclass

in the chrome/browser/gtk/browser_window_gtk.cc BrowserWindowGtk::BrowserWindowGtk 
(lines 327-370). I imagine that, as a start, one could use a "(browser_->type() & 
Browser::TYPE_APP)" conditional for its use. The "wmclass_name" should be dependent 
on the web application, as stated above. This name should match the .desktop file for 
optimal window matching in Gnome (3?), according to this doc:

http://live.gnome.org/GnomeShell/ApplicationBased

It seems like a reasonable approach might be to use the -app switch for the name. 
That would at least provide consistency for folks looking to use window matching. I'm 
not sure how command line arguments are handled exactly, so I am hesitant to do this 
myself. Here is what I thought might work, please feel free to not use this:

$ diff browser_window_gtk.cc browser_window_gtk2.cc 
342a343,349
>   if (browser_->type() & Broswer::(TYPE_APP) {
>     std::string wmclassname = 
>       CommandLine::ForCurrentProcess()->GetSwitchValueASCII(switches::kApp);
>     file_util::ReplaceIllegalCharactersInPath(&wmclassname, '_');
>     gtk_window_set_wmclass(window_, wmclassname, "chromium-browser")
>   }
> 

Again, sorry if this is unhelpful. I'm fairly new here. 
Comment 14 by evan@chromium.org, Apr 9 2010
That patch looks like a good start to me.

Because multiple instances share the process, we'd need ProcessSingleton to pass the 
name through to the new window created.  But that can be a follow-up patch.


Another, perhaps better way to accomplish this might be to have our .desktop files 
add the appropriate --name flag.  It appears that GTK supports a --name flag already, 
but I'm not sure where that shows up in the eventual app...
Just for the record, setting the --name flag does not change the WM_CLASS entries and 
leads to the following warning:

(chromium-browser:23704): GLib-WARNING **: g_set_prgname() called multiple times

This is on Ubuntu Karmic, with Chromium version 5.0.370.0 (Developer Build 43799). 
The warning message might be a bug in glib, according to a quick Google search. This 
seems especially true since searching the source gave no indication that 
g_set_prgname() is ever called by chromium. 

I do agree, though, that --name seems like the correct place to handling things like 
this. 
Comment 17 by Deleted ...@, May 17 2010
Currently using mozilla prism on linux and there's nothing like it. Looks like this 
thread could help me use chrome in this way.
Comment 18 by evan@chromium.org, May 17 2010
Labels: Pri-3 HelpWanted Mstone-X
I'd love someone to finish off a patch.  You'd probably need to diagnose the 
g_set_prgname warning (though I noticed that emacs on my system produces the same 
warning).
 Issue 62381  has been merged into this issue.
Comment 20 by evan@chromium.org, Nov 9 2010
(In duplicate  bug 62381  I describe where --name and --class go in more detail, as well as how to control them programmatically.)
Comment 21 by evan@chromium.org, Jan 27 2011
Labels: -HelpWanted GoodFirstBug
Deprecating HelpWanted label.
 Issue 42587  has been merged into this issue.
Browser::app_name_ is set to a string that is unique to the app for each app window.  Perhaps we could use that string?
Comment 24 by evan@chromium.org, Mar 8 2011
Labels: -Pri-3 Pri-2
Bumping prio since this will affect Unity.
Elliot, do you happen to be interested in this?
Comment 25 by e...@chromium.org, Mar 8 2011
Labels: -Mstone-X Mstone-12
Status: Assigned
Taking bug.
Comment 26 by e...@chromium.org, Mar 9 2011
So in r77495, WM_CLASS is now being set on app windows. docky doesn't seem to be using this information. (A grep of the docky source code in lucid leads me to believe that it isn't checking this information.) Does anything else need to be done for Unity support?
Project Member Comment 27 by bugdroid1@chromium.org, Mar 9 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=77495

------------------------------------------------------------------------
r77495 | erg@google.com | Wed Mar 09 11:11:53 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/gtk/browser_window_gtk.cc?r1=77495&r2=77494&pathrev=77495
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/browser.h?r1=77495&r2=77494&pathrev=77495

GTK: Set WM_CLASS to webapp names on webapp windows.

BUG= 20587 
TEST=1) Open chrome --app=<somesite> 2) run xprop and click the window. WM_CLASS should be set to the webapp name instead of "Google Chrome"

Review URL: http://codereview.chromium.org/6647008
------------------------------------------------------------------------
Comment 28 by psyb...@gmail.com, Mar 9 2011
Actually Docky does indeed use the WM_CLASS, you just failed to spot it in the source.  I am the Docky maintainer, trust me.
Comment 29 by evan@chromium.org, Mar 9 2011
Status: Fixed
Awesome!  So that sounds like this is fixed then, right?
Comment 30 by psyb...@gmail.com, Mar 9 2011
Seems fixed on Chromium's end.  Now it is up to the docks to use that data.
Labels: -GoodFirstBug bulkmove Hotlist-GoodFirstBug
Chrome Version       : Any
OS + version : Linux
CPU architecture (32-bit / 64-bit): Any
window manager : Any

What steps will reproduce the problem?
1. Launch a web site in app mode (such as &quot;chromium-browser --
app=http://www.gmail.com&quot;)

What is the expected result?
Each web app should be distinguishable by the Window Manager, probably by by 
having their own window class.
These classes would be used in .desktop files as the value for 
StartupWMClass

What happens instead?
Web apps look like just additional browser windows by most window managers, 
for example they will be grouped together with the browser on any type of 
panel/dock which groups application windows.


The window class could be based on the domain of the web app or something 
(like chromium-app-gmail).

Or, a simple command line option could be used in shortcuts such as 
&quot;chromium-browser --app=http://gmail.com --windowclass=Gmail&quot;
Labels: -polish Type-Polish
Comment 33 by trev...@gmail.com, Mar 25 2011
The issue with the exported WMCLASS by the application is now fixed, but the issue related to the .desktop file remains.

A desktop file generated for a web application should have a matching StartupWMClass value, and not Chromium Browser. This wouldn't allow a valid association of the desktop manager between the desktop file (icon) and the launched applicatation.
Also, the fix only seems to work for Chromium, but not Google Chrome. I'm not sure if that would be a separate bug. For instance:

google-chrome --app="http://www.gmail.com" 

Still gives "google-chome" as the WMCLASS, while the same command with 'chromium-browser' gives "www.gmail.com" as the WMCLASS.
Comment 35 by trev...@gmail.com, Mar 25 2011
Are you using a recent version? It should be fixed in Chrome 12 recent builds...
Comment 36 by f...@sofaraway.org, Mar 25 2011
apparently, it's not enough.

ShellIntegration::GetDesktopFileContents() should also tweak the StartupWMClass field when cloning the browser desktop file to create the one for the web-app.
Otherwise, there's no way unity/bamf could know it should highlight a launcher/icon in the side panel, and which one.
Comment 37 by psyb...@gmail.com, Mar 25 2011
As the Docky lead maintainer, and the developer of another dock that uses BAMF (the same window matching library used by Unity) I can tell you that the current fix is sufficient to match ONLY if the generated .desktop file(s) also have a custom StartupWMClass= entry.

So when creating a WebApp in Chromium, it also must modify the StartupWMClass to match the custom WM_CLASS entry.  At that point, BAMF can be modified to properly handle all cases.

Note that as far as I am aware, BAMF (and thus Unity) would currently still not work even after this change - BAMF itself needs some changes which use this new functionality.
Comment 38 by psyb...@gmail.com, Mar 25 2011
Oh I should point out that Docky plans to use BAMF starting in version 3.0, so whatever is needed to get this working with BAMF will also solve it for future version of Docky.
Comment 39 by trev...@gmail.com, Mar 26 2011
I'm working in BAMF, and now (after my changes) it supports this change. I'll push my fixed version as soon as I can and it will be in Natty.

However to make each application to get its desktop file associated with its window, also the StartupWMClass should match the xwindow value (as said before by me and on comment #37).
Comment 40 by evan@chromium.org, Mar 28 2011
Status: Assigned
Summary: Window class for web apps should be different from browser window (need StartupWMClass in generated .desktop entries) (was: NULL)
Ok, reopening.
Comment 41 by e...@chromium.org, Mar 28 2011
Let me make sure I understand what needs to be done here:

1) When chrome outputs a .desktop file for a web application, it needs to add a StartupWMClass= key to it.

2) From the chrome command line, we need to handle the "--windowclass=" option because whatever desktop environment is going to convert that key in the .desktop file to that command line option.

Is that accurate?
Comment 42 by trev...@gmail.com, Mar 28 2011
Yes, that should be enough.
Comment 43 by e...@chromium.org, Mar 30 2011
Labels: -Area-Misc -Size-Medium -bulkmove -Hotlist-GoodFirstBug Area-Internals Size-Large
So when we are going through BrowserInit, we have the correct command line, even if this is a new invocation on the same process (passed in over pipe to keep a single process). The big issue is that Browser and a lot of chrome look at a CommandLine singleton (CommandLine::ForCurrentProcess()) instead of keeping track of the CommandLine that created the specific Browser object. Moving from the global (at least in browser/ code) to a CommandLine object stored in Browser is a prerequisite for getting this working.

(I tried hacking it to cheat so that a browser window created during BrowserInit would get the passed in --wmclass=, but this broke when the application tried to open another window, which didn't receive the parent's wmclass.)
Comment 44 by trev...@gmail.com, Mar 30 2011
However IMHO the most urgent thing to do is to correctly generate an app .desktop file. The command line thing is just an improvement...
Project Member Comment 45 by bugdroid1@chromium.org, Apr 6 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=80656

------------------------------------------------------------------------
r80656 | erg@google.com | Wed Apr 06 11:02:41 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/web_applications/web_app.cc?r1=80656&r2=80655&pathrev=80656
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/gtk/browser_window_gtk.cc?r1=80656&r2=80655&pathrev=80656
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/web_applications/web_app.h?r1=80656&r2=80655&pathrev=80656
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/shell_integration_unittest.cc?r1=80656&r2=80655&pathrev=80656
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/shell_integration.h?r1=80656&r2=80655&pathrev=80656
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/shell_integration_linux.cc?r1=80656&r2=80655&pathrev=80656

Add the calculated WMClass to generated .desktop files.

(Also modifies it so that we only modify the wmclass_name, and not the
wmclass_class because the internal application names aren't meant for display
and are very ugly.)

BUG= 20587 
TEST=Verify with xprop that the WM_CLASS of application desktop links mmatches the StartupWMClass key in the desktop file.

Review URL: http://codereview.chromium.org/6759076
------------------------------------------------------------------------
Comment 46 by e...@chromium.org, Apr 6 2011
I think I've fixed this (r80656), but I'm not going to close the bug until I get trevi55's verification. (I didn't understand what was actually asked until Comment 44; I didn't realize that the desktop environment wasn't going to add a command line flag and that StartupWMClass was descriptive, not prescriptive. There *still* may be some misunderstandings here.)
Project Member Comment 47 by bugdroid1@chromium.org, Apr 6 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=80674

------------------------------------------------------------------------
r80674 | erg@google.com | Wed Apr 06 12:37:48 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/web_applications/web_app.cc?r1=80674&r2=80673&pathrev=80674
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/web_applications/web_app.h?r1=80674&r2=80673&pathrev=80674
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/shell_integration_linux.cc?r1=80674&r2=80673&pathrev=80674

Fix ShellIntegrationTest.GetDesktopFileContents.

(The test failure is harmless, but annoying.)

BUG= 20587 
TEST=unit tests pass
TBR=isherman@
TBR=
------------------------------------------------------------------------
Comment 48 by e...@chromium.org, Apr 11 2011
Status: Fixed
Haven't heard anything in a week. Closing bug.
Comment 49 by kknu...@gmail.com, Apr 18 2011
well, I have installed 81921 and still I have this bug...
.desktop contains: Exec=/usr/bin/chromium-browser --app=https://mail.google.com/mail
and chromium + apps will open using the same icon...
Comment 50 by trev...@gmail.com, Apr 21 2011
Sorry for the late answer erg. However as also previously stated this implementation doesn't fix the bug, since gtk_window_set_wmclass is badly used.

I've reported the fix needed in the code review at:
http://codereview.chromium.org/6759076

Without this Unity (like other window managers) will be confused.

Right now the window class for a webapp pointing to google.com is:
$ xprop | grep CLASS
WM_CLASS(STRING) = "google.com", "Chromium-browser"

While it should be:
$ xprop | grep CLASS
WM_CLASS(STRING) = "chromium-browser", "google.com"

Look at my code review and apply it. It will finally fix this issue.
Comment 51 by e...@chromium.org, Apr 21 2011
Status: Assigned
Reopening.
Project Member Comment 52 by bugdroid1@chromium.org, Apr 21 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=82581

------------------------------------------------------------------------
r82581 | erg@google.com | Thu Apr 21 16:29:09 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/gtk/browser_window_gtk.cc?r1=82581&r2=82580&pathrev=82581

GTK: Set WMCLASS in a way docks notice while still solving display issues on XFCE.

BUG= 20587 
TEST=Check xprop on the main window.

Review URL: http://codereview.chromium.org/6879127
------------------------------------------------------------------------
Comment 53 by e...@chromium.org, Apr 21 2011
trevi55: Could you test a build after r82581? If this fixes it for you, I'll try to get this merged to the M12 branch.
Project Member Comment 54 by bugdroid1@chromium.org, Apr 22 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=82672

------------------------------------------------------------------------
r82672 | erg@google.com | Fri Apr 22 11:15:17 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/gtk/browser_window_gtk.cc?r1=82672&r2=82671&pathrev=82672
 M http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/memcheck/suppressions.txt?r1=82672&r2=82671&pathrev=82672

GTK: Fix valgrind errors in previous wmclass patch.

(Can't actually read that field; need to use the glib accessor.)

BUG= 80282 , 20587 
TEST=valgrind goes green.

Review URL: http://codereview.chromium.org/6896028
------------------------------------------------------------------------
Comment 55 by e...@chromium.org, Apr 25 2011
Cc: erg%chro...@gtempaccount.com
Owner: kerz@chromium.org
krez: I'm requesting permission to merge (r82581, r82672) to the M12 branch. This was fixed incorrectly pre-branch; we should either merge these two fixes or revert r80656 from the branch.
Comment 56 by k...@google.com, Apr 25 2011
Labels: ApprovedForMerge
Owner: erg%chro...@gtempaccount.com
LGTM.
Comment 57 by e...@chromium.org, Apr 25 2011
Status: Fixed
Merged to M12.
Project Member Comment 58 by bugdroid1@chromium.org, Apr 25 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=82896

------------------------------------------------------------------------
r82896 | erg@google.com | Mon Apr 25 11:27:13 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/742/src/chrome/browser/ui/gtk/browser_window_gtk.cc?r1=82896&r2=82895&pathrev=82896

Merge 82581 - GTK: Set WMCLASS in a way docks notice while still solving display issues on XFCE.BUG=20587TEST=Check xprop on the main window.Review URL: http://codereview.chromium.org/6879127
TBR=erg@google.com
Review URL: http://codereview.chromium.org/6902003
------------------------------------------------------------------------
Project Member Comment 59 by bugdroid1@chromium.org, Apr 25 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=82898

------------------------------------------------------------------------
r82898 | erg@google.com | Mon Apr 25 11:32:31 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/742/src/chrome/browser/ui/gtk/browser_window_gtk.cc?r1=82898&r2=82897&pathrev=82898
 M http://src.chromium.org/viewvc/chrome/branches/742/src/tools/valgrind/memcheck/suppressions.txt?r1=82898&r2=82897&pathrev=82898

Merge 82672 - GTK: Fix valgrind errors in previous wmclass patch.(Can't actually read that field; need to use the glib accessor.)BUG= 80282 ,20587TEST=valgrind goes green.Review URL: http://codereview.chromium.org/6896028
TBR=erg@google.com
Review URL: http://codereview.chromium.org/6902005
------------------------------------------------------------------------
Project Member Comment 60 by bugdroid1@chromium.org, Apr 25 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=82901

------------------------------------------------------------------------
r82901 | erg@google.com | Mon Apr 25 11:46:15 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/742/src/chrome/browser/ui/gtk/browser_window_gtk.cc?r1=82901&r2=82900&pathrev=82901
 M http://src.chromium.org/viewvc/chrome/branches/742/src/tools/valgrind/memcheck/suppressions.txt?r1=82901&r2=82900&pathrev=82901

Merge 82672 - GTK: Fix valgrind errors in previous wmclass patch.(Can't actually read that field; need to use the glib accessor.)BUG= 80282 ,20587TEST=valgrind goes green.Review URL: http://codereview.chromium.org/6896028
TBR=erg@google.com
Review URL: http://codereview.chromium.org/6880178
------------------------------------------------------------------------
Project Member Comment 61 by bugdroid1@chromium.org, Apr 25 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=82900

------------------------------------------------------------------------
r82900 | erg@google.com | Mon Apr 25 11:43:12 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/742/src/chrome/browser/ui/gtk/browser_window_gtk.cc?r1=82900&r2=82899&pathrev=82900
 M http://src.chromium.org/viewvc/chrome/branches/742/src/tools/valgrind/memcheck/suppressions.txt?r1=82900&r2=82899&pathrev=82900

Revert 82898 - Merge 82672 - GTK: Fix valgrind errors in previous wmclass patch.(Can't actually read that field; need to use the glib accessor.)BUG= 80282 ,20587TEST=valgrind goes green.Review URL: http://codereview.chromium.org/6896028TBR=erg@google.comReview URL: http://codereview.chromium.org/6902005
TBR=erg@google.com
Review URL: http://codereview.chromium.org/6903002
------------------------------------------------------------------------
The bug is still here with latest version of chromium
Comment 63 by njr...@gmail.com, Jun 29 2011
Hi All,

Have been very interested in this thread for a while, but it doesn't seem to be quite getting completed as users expect - so I thought it might be good to describe the use cases to help the developers check the behaviour in context.

Unity (but also Gnome Shell, Docky, et al - not being Ubuntu-centric here) seem to rely on the WM_CLASS in order to determine whether a window should be considered part of an existing application or whether it should be considered a new instance.

This _appears_ to mean that Chromium needs to manipulate the WM_CLASS for "Application Shortcut" style web applications so that Unity will treat them as a separate application for navigation purposes (and show a separate icon in the left-hand bar).

The WM_CLASS used needs to reflect the full URL path (not just the host) of the Application Shortcut, because users often have multiple webapps sourced from the same domain. (Eg, A personal Gmail AND a Google Apps Gmail app - both using mail.google.com)

Popups
Pop-up windows requested by Webapp should be considered part of the Webapp. The new window resulting from Ctrl-clicking on a link in the Webapp should be considered part of the Webapp.

Ctrl+N
When clicking Ctrl+N from a Webapp, I would argue that the resulting window should be treated as a new browser window, not a part of the Webapp.

Cheers,

Nic


Comment 64 by trev...@gmail.com, Jul 28 2011
Sorry for bothering you again but I'm still working in the Ubuntu but that is related to this, and I guess that I proposed in codereview [1] and in comment #50 should be reverted.

I asked this due to a libwnck bug [2] that now I've fixed. Basically libwnck didn't allow us to get properly the WM_CLASS not following the related ICCCM standard [3].

According to that standard, in fact the WM_CLASS should be composed by two strings and the first one is the instance name of the window, while the second one is the Class of the window.
So for chromium standard we'd need to have something like:
 - WM_CLASS(STRING) = "chromium-browser", "Chromium-browser"

While for a web application (i.e. google.com):
 - WM_CLASS(STRING) = "google.com", "Chromium-browser"

This could be done by basically reverting the commit 82581 [4].

Thanks.

[1] http://codereview.chromium.org/6759076
[2] https://bugzilla.gnome.org/show_bug.cgi?id=168718
[3] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5
[4] http://go.3v1n0.net/r3AxI8 
Comment 65 by e...@chromium.org, Aug 3 2011
Are these changes to libwnck being backported to all previous versions of Ubuntu?
Comment 66 by trev...@gmail.com, Aug 3 2011
No, I guess they won't. However current version of ubuntu don't use correctly the chromium WM_CLASS so, this is needed in order to fix the problem in next Ubuntu versions.
Comment 67 by e...@chromium.org, Aug 3 2011
I ask because we build all our binaries on whatever the LTS release is; we can't link against libraries that aren't there. Is there a way to detect whether we're on a system that expects ICCCM conformance at runtime?
Comment 68 by trev...@gmail.com, Aug 3 2011
Well, there's a way... But you don't need that.

Chromium doesn't need to depend on libwnck, it just needs to set correctly the WM_CLASS using standard GTK (as I said above you just need to revert a commit), then BAMF (that needs libwnck) will be fixed to use the chromium WM_CLASS values.
Comment 69 by e...@chromium.org, Aug 3 2011
I want to be absolutely clear here because I'm still hazy on how all of this works and I'm fairly certain that I'm misinterpreting what you're asking for:

You want me to revert this commit: http://src.chromium.org/viewvc/chrome?view=rev&revision=80656 which is the commit created from the code review you mentioned in comment #50 and linked to as [1].

Reverting this commit will (among other things):
- Remove StartupWMClass from newly created desktop files.
- Will set the instance name to be the same as the class name.
Comment 70 by e...@chromium.org, Aug 3 2011
Are you asking me to revert http://src.chromium.org/viewvc/chrome?view=rev&revision=82581 instead? That makes more sense.
Comment 71 by trev...@gmail.com, Aug 4 2011
Yes, sorry. That's fine.
Project Member Comment 72 by bugdroid1@chromium.org, Aug 4 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=95492

------------------------------------------------------------------------
r95492 | erg@chromium.org | Thu Aug 04 14:06:05 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/gtk/browser_window_gtk.cc?r1=95492&r2=95491&pathrev=95492

GTK: Possible WM_CLASS fix.

Previously, we were setting the wmclass properties differently depending on how closely the DE we were running in was conforming to the ICCM standard. Now we just do the right thing all the time.

BUG= 20587 
TEST=none


Review URL: http://codereview.chromium.org/7562022
------------------------------------------------------------------------
Comment 73 by vcos...@gmail.com, Oct 22 2011
Hi, 
I'm using the newly release Ubuntu 11.10. I tried Chromium's app shortcuts, and they get grouped by Unity as the same application, really annoying. 

For example if i open Gmail as shortcut, and the i open another shortcut, say Facebook, Unity will display the Facebook window as Gmail instance (which means they get grouped and both have Gmail icon :/ ).

Currently I'm creating app shortcuts via Epiphany browser because the shortcuts created by it are distinguished quite well by Unity, it displays them as separate apps, as it should be.

Looking forward to have this bug fixed in Chromium. 


14.0.835.202
Comment 74 by trev...@gmail.com, Oct 26 2011
This needs to be fixed in BAMF on the ubuntu side. Chromium is already fine.
Comment 75 by vcos...@gmail.com, Oct 26 2011
Thx for the info.
Same as #73, using the latest Chromium and still having the same problems. Is the fix not applied for version 16?
Same problem with Chromium 17.0.963.79 on Ubuntu lucid, it's not fix !
Comment 78 by derat@chromium.org, Mar 14 2012
Cc: -derat@chromium.org
Project Member Comment 79 by bugdroid1@chromium.org, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 80 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Mstone-12 -Type-Polish Cr-UI-Polish Cr-Internals Type-Bug M-12
Project Member Comment 81 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment