GNOME Bugzilla – Bug 166722
gnome_url_show needs to use startup-notification and take a timestamp parameter
Last modified: 2011-01-31 17:27:37 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
This also affects launching some nautilus windows from the gnome-panel menu (see
the end of bug 166242)...
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.)
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
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.
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.
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
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?
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?
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.
> 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?
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 http://tinyurl.com/6s692 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.
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.
Is there still a bug here?
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.
And how will this be fixed in gtk+ now that gnome_url_show is deprecated?
Closing as obsolete.