After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 166722 - gnome_url_show needs to use startup-notification and take a timestamp parameter
gnome_url_show needs to use startup-notification and take a timestamp parameter
Product: libgnome
Classification: Deprecated
Component: general
Other Linux
: Normal normal
: ---
Assigned To: libgnome maintainer
libgnome maintainer
Depends on:
Blocks: 149028
Reported: 2005-02-08 22:23 UTC by Sebastien Bacher
Modified: 2011-01-31 17:27 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10

Description Sebastien Bacher 2005-02-08 22:23:40 UTC
- open a epiphany or galeon window
- gnome-open http://an_url (or click on a link in an app using gnome_url_show ())

the new window is open behind the current one instead of beeing on top

According to Elijah:
<elijah> gnome_url_show needs a timestamp parameter, and gnome-open needs to
take a timestamp argument onthe command line
Comment 1 Elijah Newren 2005-02-15 03:00:31 UTC
This also affects launching some nautilus windows from the gnome-panel menu (see
the end of bug 166242)...
Comment 2 Luis Villa 2005-02-19 17:44:27 UTC
Eh? Why should users be forced to pass a timestamp argument? The whole point of
gnome-open is to make it /easy/ for them to open something... (and I assume that
is the point of gnome_url_show() for programmers as well.)
Comment 3 Elijah Newren 2005-02-19 17:56:43 UTC
Luis: because not passing a timestamp is inherently buggy.  Metacity /needs/ to
know the time at which users initiated a program launch in order to correctly
handle focus stealing prevention.  In particular, for weird apps that
(e.g. nautilus, epiphany, galeon, gnome-terminal), not passing a timestamp means
that gtk+ defaults to assuming the new window was opened from the last user
interaction with that application, which is clearly wrong for things launched
via gnome_url_show.

Note that, due to backwards compatibility requirements if nothing else,
gnome_url_show and gnome-open will work without a timestamp, but gnome-open
should also work with a timestamp parameter and there needs to be additional API
such as gnome_url_show_with_timestamp.
Comment 4 Elijah Newren 2005-02-19 18:03:55 UTC
Oh, and let me state that we /could/ add a hack of having
gnome-open/gnome_url_show ping the xserver for a timestamp (or use
gdk_x11_display_get_user_time in the case of gnome_url_show as an imperfect
though pretty good backup--at least once we can switch over to gtk+-2.8).  This
is basically exchanging one really common bug for another that would be far less
common--I discussed this hack in the context of nautilus just yesterday on

Also, having looked at the code for gnome_url_show just a bit, part of the
problem is that startup-notification just isn't being used at all.  I'm updating
the summary accordingly.
Comment 5 Luis Villa 2005-02-19 18:14:19 UTC
This just feels very non-just-works to me :/ Why can't we just assume that
whenever gnome-open/gnome_url_show was run/called is when the user initiated the
Comment 6 Elijah Newren 2005-02-19 18:17:25 UTC
Um, we would like to assume that, by default at least.  How in the world is
gnome-open/gnome_url_show supposed to know when the user initiated the action?
Comment 7 Alexey Rusakov 2005-02-22 23:41:16 UTC
Sorry for a naive newbie question: isn't there a way gnome-open/gnome_url_show
can learn of a window they are fired from?
Comment 8 Elijah Newren 2005-02-23 00:05:12 UTC
Well, they could check their PID and thus their PPID, but finding out the parent
process doesn't do a thing for figuring out the timestamp of the user
interaction that caused the gnome_url_show function to called.
Comment 9 Luis Villa 2005-02-28 04:53:17 UTC
> How in the world is
> gnome-open/gnome_url_show supposed to know when the user initiated the action?

I think maybe we're not on the same page here. Let me re-explain what I am
assuming would be the right thing, in the gnome-open case:

* gnome-open is run by the user, say from a command line, as 'gnome-open foo.doc'
* gnome-open says $TIME == 'what time it is right now'
* gnome-open passes $TIME to startup notification.

Is that what you're saying, Elijah? Or are you saying something different?
Comment 10 Elijah Newren 2005-02-28 05:22:24 UTC
I was saying something different; you aren't trying to figure out what time the
action was initiated, but just some time later which still comes before the
actual appearing of the new window and using that to approximate the time it was
initiated.  It'd basically introduce a race condition that would break focus
stealing prevention in a hard-to-duplicate way: if a user interacted with a
window between the time they caused gnome-open to start and the time that
gnome-open obtains a timestamp without also interacting with some app after that
timestamp is obtained but before the window appeared, then the newly launched
window would erroneously and surprisingly take focus.  I hate tracking down
these kinds of bugs (and yes, they are a real problem that can occur in normal
usage; I've fixed all kinds of nasty races similar to this in Metacity this

Anyway, despite the fact that this would be introducing a race condition bug,
your idea would improve the behavior for the majority of cases when the old API
is used (i.e. without a timestamp).  One could put your idea to use by copying
the slowly_and_stupidly_obtain_timestamp() function from the patch in bug 144897
and then using it.

In fact, I think I'm going to suggest that something like this be done for those
weird apps who really need to be launched with startup-notification whenever
they aren't launched that way (see for more details);
it's a sort of an ugly hack, but it'll at least be correct behavior in the
majority of cases where startup-notification isn't used instead of vice-versa.
Comment 11 Elijah Newren 2005-02-28 21:27:54 UTC
I've written patches for gnome-terminal, nautilus, epiphany, and galeon to try
to gracefully handle not being launched with startup-notification.  I'm going to
assume those will get applied and remove this from the list of 2.10 showstoppers.
Comment 12 Kjartan Maraas 2006-10-23 12:48:12 UTC
Is there still a bug here?
Comment 13 Elijah Newren 2006-10-23 17:23:03 UTC
Yes, epiphany/galeon/nautilus/gnome-terminal and other apps have just been introducing hacks to workaround it in race-condition like ways.  The root problem is still very much there.
Comment 14 Kjartan Maraas 2009-05-04 07:45:33 UTC
And how will this be fixed in gtk+ now that gnome_url_show is deprecated?
Comment 15 Kjartan Maraas 2011-01-31 17:27:37 UTC
Closing as obsolete.