GNOME Bugzilla – Bug 647437
Window title is 'java-lang-Thread' instead of actual application name
Last modified: 2021-07-05 14:42:03 UTC
When I run Netbeans 7.0RC2 under Gnome Shell, the window name shown in the top panel is 'java-lang-Thread', whereas the actual window title, as displayed by Mutter, is '<project title> - NetBeans IDE 7.0 RC2'.
This is an application bug - if it's not setting WM_CLASS to anything meaningful, we can't really hope to associate the window properly with the application. We do have some support for hardcoding regular expressions on window titles, but this doesn't work well with translation. See http://live.gnome.org/GnomeShell/ApplicationBased
If it's an application bug, then all Java Swing applications I've encountered yet under Gnome Shell suffer from it. FWIW, the wiki page you link to says: "The window data (icon, and title) are de-emphasized in GNOME 3. Instead, the top area will contain a persistent display of your application's .desktop file name.". The Netbeans .desktop file itself as well as the Name property in it refer to Netbeans and not to java.lang.Thread!
There's nothing we can do about apps that don't identify themselves with properties on the top level. Setting WM_CLASS to java-lang-Thread violates the definition of WM_CLASS in the X interclient conventions manual (ICCCM).
Reinout: The problem is that the Shell needs WM_CLASS to match the .desktop file name. When it doesn't, there's no way to identify the application, thus the ugly WM_CLASS is used.
(In reply to comment #4) > Reinout: The problem is that the Shell needs WM_CLASS to match the .desktop > file name. When it doesn't, there's no way to identify the application, thus > the ugly WM_CLASS is used. OK. The relevant Netbeans bug is here: http://netbeans.org/bugzilla/show_bug.cgi?id=183739
*** Bug 656017 has been marked as a duplicate of this bug. ***
FWIW, the Netbeans developers think this is a JDK issue.
See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6528430
Is this still an issue? At least the netbeans bug has been closed by now ...
The NetBeans bug was closed by using enough reflection to set sun.awt.X11.XToolkit.awtAppClassName: http://hg.netbeans.org/main-golden/rev/5832261b8434 Probably the real fix has to come in OpenJDK.
(In reply to comment #10) > Probably the real fix has to come in OpenJDK. Agreed, but I haven't used any java GUI applications in years, so I don't know whether that fix has happened by now or not (and asking on this bug is just so much easier than starting to digg through JDK bug trackers :-) If you can confirm that the issue persists, feel free to change the status back to UNCONFIRMED.
JDK bug #6528430 is still open. (Java AWT makes a half-hearted attempt to guess at a WM_CLASS based on inspecting the stack trace in effect when it is initialized, but this is only going to be reasonable in English locale for trivial applications.) gnome-shell _could_ work around the problem in the meantime by ignoring certain values of WM_CLASS known to be bogus. I am not sure whether java-lang-Thread is the most likely single value, though. Probably gnome-shell should punt on this and leave it to OpenJDK to fix.
Why not to fall back to WM_NAME? At least this will look less ugly.
We do. We fall back to _NET_WM_NAME and then WM_NAME.
Jasper, sorry, can't confirm this. In my tests, for a window with following properties gnome-shell 3.6 still shows "main-FocusTest" in the panel: WM_CLASS(STRING) = "sun-awt-X11-XFramePeer", "main-FocusTest" _NET_WM_NAME(UTF8_STRING) = "A Focus Test" WM_NAME(STRING) = "A Focus Test"
Roman: my understanding is that if WM_CLASS is set, then gnome-shell trusts it; WM_NAME is used only if it is unset, as a fallback. Which is fine. The problem is that AWT *does* set WM_CLASS, but very crudely (according to the implementation class name it first finds in the caller stack).
Jesse, I think exactly the same. My suggestion was to use [_NET_]WM_NAME not only when WM_CLASS isn't set, but also when a corresponding .desktop file for a given class wasn't found.
Note that this is only the most visible effects of a missing .desktop file - incorrect grouping in dash/alt-tab, fuzzy icons and the inability to add the app to favorites are others. So yes, we can do better to paper over the problem in this particular case, but that would also take away some incentive to fix the underlying problem.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
(In reply to comment #19) > Closing this bug report as no further information has been provided. Please > feel free to reopen this bug if you can provide the information asked for. > Thanks! What kind of information did you still need? AFAIK this bug still affects many Java GUI apps.
(In reply to comment #20) > AFAIK this bug still affects many Java GUI apps. OK, reopening and removing needinfo.
I' m on gnome 3.12.1. MATLAB also suffers from this problem, together with wrong group windows. And chrome window title is now Google-chrome-stable, not sure if related. All other Desktop I've used (KDE and Unity and old gnome) doesn't have this problem. So there is definitely a way to make it right for the users, though not very clean. But why make users suffer from a common nearly unfixable developer error for so long? (MATLAB itself doesn't even provide a .desktop file, how can you expect users know how to get .desktop files right with a shell?)
(In reply to comment #22) > And chrome window title is now Google-chrome-stable, not sure if related. Window titles work fine, the problem are *application* names when we cannot figure out what application a window belongs to. As mentioned before, there is quite a bit of functionality that won't work as expected in that case, the wrong app name just being the most visible issue. It happens that we could pick a nicer fallback for the app name, but the result would just be a subtly broken app instead of an obviously broken one - taking away incentive to fix the app in the first place. Any suggestions on making the window <-> application association work in more cases are very welcome, however making broken applications just look better (rather than actually fixing the problem) is much less interesting.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.