GNOME Bugzilla – Bug 641532
search results aren't focused
Last modified: 2012-02-17 15:46:23 UTC
If I do a search and select 'Google', it properly opens the search results in my browser. However, if the browser is on another workspace, I'm not switched there. I can see arguments both ways, here - when I'm opening a link in various places (xchat, terminal, etc.), I *don't* want the web browser to steal my focus and become the foreground app. However, if I'm explicitly opening a search page, I might want the shell to jump there. gnome-shell-2.91.6-3.fc15.1.x86_64 firefox-4.0-0.13b10.fc15.x86_64
Actually the browser should be in the foreground when you click a link somewhere too.
Created attachment 180955 [details] [review] search: add openUrl It determinate default browser. Switch focus to last active window of browser(link will always open here). open url.
Comment on attachment 180955 [details] [review] search: add openUrl >+ try { >+ Gio.app_info_launch_default_for_uri(url, global.create_app_launch_context()); >+ } catch (e) { >+ // TODO: remove this after glib will be removed from moduleset >+ // In the default jhbuild, gio is in our prefix but gvfs is not >+ Util.spawn(['gvfs-open', url]) >+ } so, this whole patch is essentially a workaround for this workaround; gvfs-open doesn't pass an event time, and so the app it spawns gets focus-stealing-prevented. We ought to be able to address this more directly.
(In reply to comment #3) > so, this whole patch is essentially a workaround for this workaround; No. Browser (that started with url in args) will _always_ open new tab in window with greatest user_time (even it in other workspace).
(In reply to comment #3) > (From update of attachment 180955 [details] [review]) > >+ try { > >+ Gio.app_info_launch_default_for_uri(url, global.create_app_launch_context()); > >+ } catch (e) { > >+ // TODO: remove this after glib will be removed from moduleset > >+ // In the default jhbuild, gio is in our prefix but gvfs is not > >+ Util.spawn(['gvfs-open', url]) > >+ } > > so, this whole patch is essentially a workaround for this workaround; gvfs-open > doesn't pass an event time, and so the app it spawns gets > focus-stealing-prevented. We ought to be able to address this more directly. The timestamp issue is actually fixed by https://bugzilla.gnome.org/show_bug.cgi?id=642188#c8 (the browser opens in the forground and does not get focus-stealing-prevented).
so is this still relevant?
Not sure. It still doesn't switch to the window for me, but that may be a FF preference of mine.
Still reproduceable here.
So, basically, we have a consistent desktop behavior whether you are opening a web URL from: * A search result * A link in the message tray * A link in gnome-terminal or evolution That if there is an existing browser window: We open the link in that browser window, and let the browser show an "is ready" notification, but don't switch to the browser or switch workspace If there is no existing browser window: We open a new browser window and focus it So the questions are: * Is that the right behavior in general? * Do we want to behave differently here because we're in the overview and not interacting with a specific application - we are "switching context"? * If we change the behavior for this, what about clicking on links in the message tray?
The current behavior really stinks actually. A user clicking a link is an explicit request and so focus stealing prevention stuff doesn't really apply. We should always be presenting the resulting page to the user and never use a notification. The user's is really requesting "give me the darn page" not "pull the page into memory and let me know when that is done". Using a notification is particularly wacky when the link is in the message tray. The result is that you don't even see the notification. Clicking a link should always bring that page to the foreground. If the page is loaded just raise the app. If the page isn't loaded but the app is open bring the app forward and show a loading progress in the app. If the app isn't running start the app in the foreground and load the page. If the link was activated from the message tray I think it is an open question whether this causes a focus change. I think it might be fine to just load the page and retain focus in the tray. Which is more or less the current behavior modulo the loading the page in the background and hidden.
I created: https://bugzilla.mozilla.org/show_bug.cgi?id=721498 with a patch for Firefox that makes it use a correct timestamp when it raises an existing window in response to the remote protocol, instead of always using 0. This makes things work as expected for the search, at least when there's a Firefox on the current workspace. When Firefox is on a different workspace, you get a notification rather than being warped to that workspace.
(In reply to comment #11) > When Firefox is on a different workspace, you get a notification rather than > being warped to that workspace. Actually, this solution has some merits. It could be used by advanced users that use workspaces to control when Firefox gets focused, and when it doesn't. FWIW, I liked the current behavior, even if it wasn't intended that way. When reading my bugmail, I open interesting reports, and treat them in one row from Firefox without going back to Evolution. I find it more efficient. I agree this is not ideal for everybody, though, but I'll be able to preserve the current behavior by putting Evo and Firefox on different workspaces.
*** Bug 659267 has been marked as a duplicate of this bug. ***
Firefox patch landed, closing this bug