GNOME Bugzilla – Bug 150085
window focus bugs
Last modified: 2011-09-22 22:56:08 UTC
From this thread on d-d-l: http://mail.gnome.org/archives/desktop-devel-list/2004-August/msg00158.html "When does it break: the most common problem right now is launching new windows for existing apps. e.g. clicking the Epiphany launcher while Epiphany is already running. In this case, the timestamp from the startup notification does not get forwarded to the new Epiphany window; instead the timestamp from the last interaction with Epiphany is used. So it's likely that the new window won't be focused. [...] Even if that fix goes in, the truly correct change is for epiphany to forward the timestamp (and the startup notification ID) to the new window from the launch sequence. gnome-terminal has an example of doing this for startup notification ID."
Created attachment 30587 [details] [review] completely untested, half-finished patch based on what gnome-terminal does in terminal-window.c
Note that as pointed out by Lubos in that thread, the startup-notification spec made it impossible to fix this (the TIMESTAMP couldn't be obtained by apps and thus couldn't be forwarded). There are patches in bug 151245 that implement a proposed addition to the spec (including an implementation of that addition), along with a patch for gnome-terminal which implements the forwarding of the startup notification timestamp. I'm marking this bug as blocking 151245 and adding myself to the cc list.
Target: 1.4 -> 1.6
focus-stealing-prevention has been disabled in Metacity, so this bug is irrelevant for the 2.8.0 release (well, except for people using Kwin as their window manager, but I don't know if we're worried enough about that to break hard code freeze). I'm changing the Gnome Milestone to 2.10.0.
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
HOW-TO: http://mail.gnome.org/archives/desktop-devel-list/2004-December/msg00306.html
Created attachment 36747 [details] [review] new patch Elijah: could you take a look at this patch and tell me if I'm doing this right? Thanks.
Awesome, looks really good. There is one more corner case that would be sweet if you could handle (though don't fret too much about it, since I have never seen it handled correctly). Consider the following two situations: 1) a) User open a URL in a web browser for a site which happens to be down b) User waits for site to load c) Epiphany pops up an error saying the site could not be found 2) a) same as above b) User open another URL in a different tab while waiting c) same as above In the first of these two cases, the error dialog stating that the site could not be found should be focused; in the latter, it shouldn't be. The way to handle this is to record the timestamp of when the user hit the enter key, and use that in call gdk_x11_window_set_user_time on the error dialog that appears.
Unfortunately, we can't do that, since the dialogue comes from mozilla... I've discovered on more case: we show the filechooser on a save action only when the server responds to our request; so I'll have to forward the user time to EphyEmbedPersist too. Is gtk_get_current_event_time () / the |time| value in a GdkEvent* the right time to get (i.e. when the user has activated a menu item) as user_time param?
Doh! We need to find someone to patch Mozilla... Yes, gtk_get_current_event_time() or the time value from a GdkEvent* are the right time to get, so long as they correspond to a user input event (e.g. if the GdkEvent is for a ButtonPress or KeyPress event, but not if the GdkEvent is for a MapNotify or something like that).
I've checked in more user time changes (for ephy-embed-persist and related things, and for launching applications). What remains: - update user time when showing the downloader - find some way (or file a bug upstream) to get the user time from mozilla for content handlers / downloads
Summarising from irc: We can get the time of the start of the download from nsIExternalHelperAppService.idl / some param in nsITransfer. While that's not the best timestamp, it's certainly better than gtk_get_current_event_time(). The problem is that it's a real time, while user-time is a number of milliseconds since the xserver was started, with no obvious way to convert (but see bug 151984).
Is this still relevant with the webkit version, 3.0 and gnome-shell that encourages single window instances?
Christian, is the bug still relevant in epiphany 3.0 ?