Description of problem: If Firefix is running, and you drag the icon for Firefox from the Favorites bar on the left over to the bottom workspace on the right, it will create a new workspace, then destroy the workspace you dragged the icon to, and the new workspace takes the place of the old one. The new Firefox window appears on the existing workspace. Version-Release number of selected component (if applicable): gnome-shell-3.7.92-2.fc19.x86_64 How reproducible: every time Steps to Reproduce: 1. start with a fresh login to Gnome with no applications running 2. start Firefox 3. go the Activities overview 4. click-and-drag the Firefox icon (NOT the window!) from the Favorites bar to the bottom workspace on the right Actual results: the bottom workspace is destroyed, a new one takes its place, and the new Firefox window appears on the workspace with the old Firefox window Expected results: a new Firefox window appears on the new workspace Additional info:
Yup. Yup, it does exactly that. Confirmed, with gnome-shell-3.8.3-1.fc19.x86_64 . Jeff, you might be able to get more traction if you report this upstream to bugzilla.gnome.org ?
Note, Nautilus behaves almost the same, only slightly worse: the jiggery-pokery with the empty workspaces happens when you release the button to complete the drag, but the Nautilus window does not appear on the top workspace thumbnail or in the overview. It only pops into existence when you leave the overview. (For me, anyhow).
drago01 says: "Sounds like a firefox bug (not doing startup notification properly)."
I see similar behavior with Nautilus. If both Firefox and Nautilus trigger this bug, are you sure it's a Firefox bug?
(In reply to Adam Williamson from comment #1) > Jeff, you might be able to get more traction if you report this upstream to > bugzilla.gnome.org ? See https://bugzilla.gnome.org/show_bug.cgi?id=702114
Jeff: well, I saw the Nautilus thing too, but as I noted it's slightly different. I guess we might want to report that separately against Nautilus.
Can you provide more info what do you mean with "not doing startup notification properly"? That's a bit vague information without any added value :)
(In reply to Adam Williamson from comment #3) > drago01 says: > > "Sounds like a firefox bug (not doing startup notification properly)." Adam, can you get more info on this? I don't know who drago01 is.
drago01 is Adel Gadllah, drago01 is his IRC nick, he's often on freenode and GIMPnet. I'll try and find his bugzilla email.
(In reply to Martin Stransky from comment #7) > Can you provide more info what do you mean with "not doing startup > notification properly"? That's a bit vague information without any added > value :) This feature works this way: We call shell_app_launch (gnome-shell) with the workspace set to the desired workspace (i.e the one the user dropped the launcher on). There we create an new launch context (see gdk/gdkapplaunchcontext.c in gtk) with this workspace set. And call g_desktop_app_info_launch_uris_as_manager (glib) which ends up in g_desktop_app_info_launch_uris_with_spawn (glib) .. this one sets the DESKTOP_STARTUP_ID environment variable pointing to the launch context (which includes the desktop/workspace). Apparently Firefox ignores that or handles it wrongly. See: http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt for details.
Firefox reads the DESKTOP_STARTUP_ID - http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3275 but it depends when the DESKTOP_STARTUP_ID is set.
It's because DESKTOP_STARTUP_ID variable is empty.
*** Bug 1018085 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.