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 don't-open-a-window-but-instead-request-that-a-previous-instance-do-it-for-them (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.
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 nautilus-list. 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 action?
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 cycle)... 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.