GNOME Bugzilla – Bug 691643
Firefox restart produces additional item on dash
Last modified: 2018-07-13 20:32:07 UTC
Created attachment 233365 [details] Screenshot When Firefox (maybe other apps, too) crashes or restarts (after installing an update), the dash tray shows a second item and the real Firefox launcher looks inactive. In detail: 1.) add Firefox to the dash as a favourite 2.) launch Firefox 3.) wait for it to crash and restart or apply an update and let it restart => the real launcher now looks inactive, a new one appears at the bottom => clicking the real launcher opens a new window and does not bring up the existing Firefox window
This is probably because the Shell is not able to associate the new Firefox window with its .desktop file. What is the WM_CLASS of the Firefox window after restart (use 'xprop' to find this out)? Is it different from that of the original window? What's the name of the .desktop file?
You can also look at what applications are associated with each window and launcher in the looking glass (alt-f2, lg), in the windows tab.
Looks like I was partially wrong: the restart on update does not seem to trigger this problem after all. WM_CLASS seems to be "Firefox" all the time, for all builds (Stable, Beta, Aurora, Nightly) The .desktop files do not all match the WM_CLASS - is this the problem? If so, I can only fix it for one build, by naming the .desktop file "firefox.desktop"?
What are the desktop file names? Good ones would be firefox.desktop, mozilla-firefox.desktop or mozilla/firefox.desktop. If they're different, you should file a bug at your distribution, or Firefox upstream if you're using the pre-built binaries. Btw, the issue here is probably a restart of the shell, which loses the association done using the PID of the launched process.
The problem really is that I run different builds and use desktop files like firefox-beta.desktop, firefox-aurora.desktop and firefox-nightly-desktop I could use firefox.desktop for one, but that would not solve the problem for the other builds... as the window class is the same on all build channels :/
(In reply to comment #5) > I could use firefox.desktop This breaks the whole setup. It surely works great for only one Build, but as soon as I start the second one (which does not use firefox.desktop) the Dash also associates it with the first launcher...
(In reply to Giovanni Campagna from comment #4) > Btw, the issue here is probably a restart of the shell, which loses the > association done using the PID of the launched process. That bit is the same as bug 665204. (In reply to Michael Monreal from comment #5) > I could use firefox.desktop for one, but that would not solve the problem > for the other builds... as the window class is the same on all build > channels :/ In other words, there are three windows that all identify themselves as "firefox", and we should somehow correctly differentiate those as "firefox-beta", "firefox-aurora" and "firefox-nightly" ... The only option I see is saving startup information in an X11 property as proposed by Jasper in the other bug, but that only fixes the issue of shell restarts, and only works for windows that have been launched through the shell (not firefox restarting itself or running from alt-f2/terminal). So not sure how useful it is. *** This bug has been marked as a duplicate of bug 665204 ***