GNOME Bugzilla – Bug 640441
Evince (still/again) steals focus upon automatic document refresh
Last modified: 2018-05-22 14:08:15 UTC
When evince shows a document (e.g., mylatexfile.pdf) that is then altered (e.g., by editing and compiling mylatexfile.tex), evince updates the document, which is a good thing. However, it also steals the focus, i.e., pops up into the foreground, which is generally not considered the proper behaviour. (This is the same issue as for evince 2.24 here: https://bugzilla.gnome.org/show_bug.cgi?id=571051 and here https://bugzilla.gnome.org/show_bug.cgi?id=592821 ) Even though I gather that the first one was claimed to have been resolved for the core issue, it seems that the bug either still persists or has been re-introduced somehow, as also indicated by these two much more recent threads: https://bugs.launchpad.net/evince/+bug/664448 http://groups.google.com/group/fr.comp.applications.emacs/browse_thread/thread/8e3fcec3b51b7af5/c6323f1a66ab5daa?#c6323f1a66ab5daa Note that all wishes that evince better not auto-update should be ignored -- evince should simply not steal the focus, but of course auto-update as it always did. My specs: > uname -a Linux xxx 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 CET 2011 x86_64 Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux > evince --version GNOME Document Viewer 2.32.0 > awesome --version awesome v3.4.9 (Smack) • Build: Jan 23 2011 22:11:32 for x86_64 by gcc version 4.5.2 • D-Bus support: ✔
I confirm this bug on ubuntu with evince version 2.32.0. The same focus stealing happens here. I work in my editor and trigger make to update the document. In the middle of the continued typing the focus is lost to evince. This will be even worse for setups like flymake, where the document is updated in the background by the editor without explicit user actions. I use the gnome with compiz as WM.
@Dpl, @martin, how are your Window manager "Stealing focus" settings are configured?
I have focus follows mouse activated and I think I have not changed the default setting in gnome (actually I cannot find it right now).
I use the standard awesome rc.lua configuration, which should be available here: http://git.naquadah.org/?p=awesome.git;a=blob_plain;f=awesomerc.lua.in;hb=HEAD Basically focus also follows cursor. Other users with non-standard rc.lua config have however reported a short flashing up and getting focus of some message window (or s.th. similar) and then the focus going back to the window which held focus before. I was however unable to trace down the decisive line exactly, BUT: I found out that it for me only happens when evince is in fullscreen mode, which may or may not be equivalent to a maximised window in other WMs.
I am not using it in fullscreen, it is just hovering on my second monitor (xinerama) but not fully covering it.
The awesome user list gave a confirm for Fedora 9 & awesome. There, it was also noted that one should distinguish between a widow "being on top" and "having the focus", i.e. the two aspects of whether i) which windows covers what other windows and ii) where the keystrokes get sent. Also, the list of variables to be examined grew to: maximized or not, fullscreen or not, same virtual desktop or not, same screen(=monitor) or not. And I have to refine my last post: it happens for me when either in fullscreen or maximized mode, but not if neither of those
What's the status on this? Is someone willing to implement an option to disable focus stealing? Also I've got a related bug that's even worse: I use emacs with some wmctrl-based script to bring the evince window into focus whenever I compile. Usually, that means having an evince window in a virtual desktop, and emacs in another one. When the evince window is maximised, I sometimes get the following (really buggy) behaviour: I compile, the script switches me to the evince desktop. There, a fraction of a second later, evince auto-updates the document and tries to steal focus (which it already has, thanks to the wmctrl bit). Somehow, evince actually _loses_ focus, and the window becomes greyed and doesn't receive keyboard input. This is obviously very annoying, especially for latex users. (using evince 2.23.0 on ubuntu 10.10)
I think the problem was that the "spinner loading" window was stealing the focus, and if I remember correctly, Carlos fixed that in Master. Please try with evince from git master, or post your script plus exact steps to reproduce so I can take a look at this. The behavior you are experiencing is clearly not normal as if evince has the focus, it should not loose it when a reload is made.
I'll have to wait until I upgrade to ubuntu 11.4 to test it, since it appears to require gnome 3.0 (unless you can point me to a specific patch, or a version where the bug is fixed but that still compiles under ubuntu 10.10) My script is basically a wrapper around wmctrl -a something.pdf. To reproduce the bug, - Maximize the evince window - Switch to another desktop - Modify the latex source and make (or possibly simply touch something.pdf) && wmctrl -a something.pdf (the wmctrl needs to be done before the auto-reload occurs) This is kinda hard to reproduce : sometimes it loses focus, sometimes it doesn't, and the bug seems to only trigger when significant changes are made to the document.
Actually, if it's related to what I am thinking, then this one line patch should make the focus stealing disappear. http://git.gnome.org/browse/evince/commit/?id=464ec9077f4bc709e50c83372c9d4e1703533efa
It's getting weirder and weirder. It does seem to be working when I patch http://archive.ubuntu.com/ubuntu/pool/main/e/evince/evince_2.32.0.orig.tar.gz, do ./configure, make, cd shell, ./evince. But when I make install and run evince from /usr/local/bin/, then I once again run into the issue. I've double checked that the evince from /usr/local/bin is the one I patched, and it doesn't have the menu entries from the ubuntu version, so the code running is the right one. I've also killed evinced, just to make sure. Any idea where that might come from? Apart from that, the patch does seem to fix this issue. However, if I recompile some latex in virtual desktop 1 and evince is in 2, the GtkSpinner is displayed even in desktop 1, which is annoying.
*** Bug 592821 has been marked as a duplicate of this bug. ***
This bug persists in evince 3.14, 3.16, 3.18.2 in ubuntu (compiz) and gentoo (mutter). Setting org.gnome.desktop.wm.preferences: focus-new-windows = strict, the presence of gnome extensions, and the setting of focus-mode seem to have no affect on the behavior. To reproduce: 1. run evince on any pdf file from a gnome-terminal window: $ evince file.pdf & -- evince shows popup notification and the focus returns to the terminal window 2. do it again -- just recall the command $ evince file.pdf & -- now the popup notification is not shown and the focus does not return to the terminal window
I do not know what do you mean by "popup notification" as I do not see any. However, I can see the different behaviour between opening a document for the first time and evince getting the focus when it is called with a document already opened.
One of these https://en.wikipedia.org/wiki/Pop-up_notification https://help.gnome.org/users/gnome-help/stable/shell-notifications.html.en typically pops up when a window opens in the background. Could "focus-new-windows" be rephrased to include the refresh or update of existing background windows?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/200.