Bug 156710 - firefox pop under/startup notify bug
firefox pop under/startup notify bug
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
FF3RawhideClose
:
: 185125 (view as bug list)
Depends On:
Blocks: FC4Update
  Show dependency treegraph
 
Reported: 2005-05-03 11:14 EDT by Ray Strode [halfline]
Modified: 2007-12-20 11:47 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-20 11:47:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Run the Red Panda (1.57 KB, text/plain)
2005-05-09 15:16 EDT, Ray Strode [halfline]
no flags Details
Slightly less crackful version (1.60 KB, text/plain)
2005-05-09 16:35 EDT, David Zeuthen
no flags Details
updated version (1.79 KB, text/plain)
2005-05-09 17:22 EDT, David Zeuthen
no flags Details

  None (edit)
Description Ray Strode [halfline] 2005-05-03 11:14:49 EDT
If firefox is already running and it gets told to create a new instance of
itself from another application, the new window will pop under the currently
focused window.  This is a side effect of Elijah Newren's "focus stealing
prevention" work.

See: http://mail.gnome.org/archives/desktop-devel-list/2004-December/msg00306.html

Firefox is a particularly important application to get fixed because it's so
widely used.
Comment 1 Ray Strode [halfline] 2005-05-04 16:17:49 EDT
The desktop core team did some testing today and it turns out this is going to
take fixing in firefox and any program that launches firefox.

Firefox basically needs to do bullet point number 4 in Elijah's mail, and all
programs that launch firefox need to start it with the DESKTOP_STARTUP_ID
environment variable set to the format specified in Elijah's mail using the
timestamp of the user event.

For programs that use gnome_url_show they can probably be changed to use
gnome_url_show_with_env ().  Only some events from X have timestamps associated
with them and the mouse button press event isn't one of them, so in most cases a
program is going to have to call gdk_x11_get_server_time () when a user clicks
on a link to get the timestamp information needed for DESKTOP_STARTUP_ID.

Fixing all programs before FC4 is obviously to far reaching of a goal, but if we
get evolution, gaim, xchat, and gnome-terminal that should cover enough of the
cases to be acceptable.  If we can't get at least those, we should probably just
disable startup notification for FC4.
Comment 2 Ray Strode [halfline] 2005-05-09 15:16:59 EDT
Created attachment 114178 [details]
Run the Red Panda

The desktop core team wrote this program while sitting in a meeting to test
random programs for focus stealing badness...

Put in the path to a program in the box and click "Run the Red Panda".	If the
program doesn't take focus then it needs to be fixed.
Comment 3 Warren Togami 2005-05-09 15:24:57 EDT
For gaim, would DESKTOP_STARTUP_ID environment variagble handle all pop-up
dialogs including a new chat session when they are threads of the same process?

Keep in mind that gaim is NOT ALLOWED TO link to GNOME libraries beyond and
glib2 and gtk2.  Does this make this unfixable?
Comment 4 David Zeuthen 2005-05-09 16:35:15 EDT
Created attachment 114181 [details]
Slightly less crackful version
Comment 5 David Zeuthen 2005-05-09 17:22:47 EDT
Created attachment 114185 [details]
updated version

Compile with "gcc -o foo foo.c `pkg-config --cflags --libs gtk+-2.0`". 

Now you get two buttons a) "Launch with DESKTOP_STARTUP_ID set (after five
secs)" and b) "Launch with DESKTOP_STARTUP_ID unset (after five secs)". 

When pressing either button the desired program will be launched after five
seconds either with DESKTOP_STARTUP_ID set or unset (as appropriate). Let us
consider an application (gedit) that is working:

 1) Launch with DESKTOP_STARTUP_ID set (after five secs)
    Enter gedit in the entry box and press "Launch with DESKTOP_STARTUP_ID set
(after five secs)". Do nothing. After five seconds gedit should be launched and
it should take the focus.

 2) Launch with DESKTOP_STARTUP_ID set (after five secs)
    Enter gedit in the entry box and press "Launch with DESKTOP_STARTUP_ID set
(after five secs)". Immediately after press tab to continue interacting with
the launcher. After five seconds gedit should be launched and it SHOULD NOT
steal focus.

When launching via the "Launch with DESKTOP_STARTUP_ID unset (after five secs)"
button, the application should always steal focus.
Comment 6 David Zeuthen 2005-05-09 17:27:06 EDT
Replacing firefox with gedit gives identical results. Firefox does respect the
DESKTOP_STARTUP_ID environment variable. This works if no instance of Firefox
were running already. In an instance of firefox is running already case number 1
always fail. That is the core of this bug.

Another question is whether Firefox sets the DESKTOP_STARTUP_ID variable for
helpers, but that is another bug.
Comment 7 Ray Strode [halfline] 2005-05-25 16:09:22 EDT
This is obviously not going to get fixed for FC4 GA.  Let's get it off the
tracker list.
Comment 8 Christopher Aillon 2006-03-11 18:10:13 EST
*** Bug 185125 has been marked as a duplicate of this bug. ***
Comment 9 Robert O'Callahan 2006-05-16 16:08:28 EDT
See https://bugzilla.mozilla.org/show_bug.cgi?id=223492 which I'm going to fix
shortly. When that's fixed, we still need GTK applications to be fixed. However,
I'm going to try to make Firefox's "remote open" pass the current server time to
be used with _NET_ACTIVE_WINDOW, if DESKTOP_STARTUP_ID isn't available, so
remote opens will get focused (possibly incorrectly).
Comment 10 Matěj Cepl 2007-12-20 11:47:37 EST
We just updated the Firefox version in Fedora/development from 2.0 to a 3.0
pre-release version, which improves performance, memory usage, and fixes many
bugs and crashes.

Closing as CANTFIX since we aren't fixing bugs filed against 2.0 now that 3.0 is
in.  If this bug is still present in rawhide using a Firefox 3.0 version, please
re-open this bug.

Thanks and Happy Holidays

Note You need to log in before you can comment on or make changes to this bug.