GNU bug report logs - #17439
24.3.50; run-with-idle-timer runs on focus-out

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17439 in the body.
You can then email your comments to 17439 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; run-with-idle-timer runs on focus-out
Date: Thu, 08 May 2014 23:45:27 +0300

Some change a few months ago introduced a significant inconvenience.
After switching to another application, the focus returns back to Emacs.
It happens when using `mouse-avoidance-mode' customized to `banish'.
This mode relies on `run-with-idle-timer' that moves the mouse cursor
on a new input.  This caused no problems in prior releases.

However, now input events include a new event type `focus-out',
so the mouse cursor is moved on switching from Emacs frame
(and the new mouse cursor position puts the focus back
due to specific configuration).

This code illustrates the problem:

(defun test () (message "%S" last-input-event))
(setq timer (run-with-idle-timer 0.1 t 'test))

On switching out it prints to *Messages*:

(focus-in #<frame emacs <at> localhost 0x1121908>)
(focus-out #<frame emacs <at> localhost 0x1121908>)

This specific problem can be fixed by this patch:

=== modified file 'lisp/avoid.el'
--- lisp/avoid.el	2014-01-31 06:42:29 +0000
+++ lisp/avoid.el	2014-05-08 20:39:59 +0000
@@ -343,7 +343,8 @@ (defun mouse-avoidance-ignore-p ()
 		 (let ((modifiers (event-modifiers (car last-input-event))))
 		   (or (memq (car last-input-event)
 			     '(mouse-movement scroll-bar-movement
-					      select-window switch-frame))
+					      select-window switch-frame
+					      focus-in focus-out))
 		       (memq 'click modifiers)
 		       (memq 'double modifiers)
 		       (memq 'triple modifiers)

PS: it seems there are other places that check only for `switch-frame',
and not for new event types `focus-in' and `focus-out'.  But maybe
this problem occurs only in `run-with-idle-timer' because switching out
doesn't emit the event on its own, i.e. `read-event' doesn't return it.

Message #8 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Fri, 09 May 2014 09:28:21 +0300

> From: Juri Linkov <juri <at> jurta.org>
> Date: Thu, 08 May 2014 23:45:27 +0300
> 
> Some change a few months ago introduced a significant inconvenience.
> After switching to another application, the focus returns back to Emacs.
> It happens when using `mouse-avoidance-mode' customized to `banish'.
> This mode relies on `run-with-idle-timer' that moves the mouse cursor
> on a new input.  This caused no problems in prior releases.
> 
> However, now input events include a new event type `focus-out',
> so the mouse cursor is moved on switching from Emacs frame
> (and the new mouse cursor position puts the focus back
> due to specific configuration).
> 
> This code illustrates the problem:
> 
> (defun test () (message "%S" last-input-event))
> (setq timer (run-with-idle-timer 0.1 t 'test))
> 
> On switching out it prints to *Messages*:
> 
> (focus-in #<frame emacs <at> localhost 0x1121908>)
> (focus-out #<frame emacs <at> localhost 0x1121908>)
> 
> This specific problem can be fixed by this patch:

Why did you add focus-in as well?  Wouldn't you want the mouse moved
when you are about to type?

Message #11 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Fri, 09 May 2014 23:35:20 +0300

> Why did you add focus-in as well?

When I tried to switch out with

(defun test () (message "%S" last-input-event))
(setq timer (run-with-idle-timer 0.1 t 'test))

it prints to *Messages* both lines:

(focus-in #<frame emacs <at> localhost 0x1121908>)
(focus-out #<frame emacs <at> localhost 0x1121908>)

`focus-in' is fired by the desktop window switcher
that shows the list of desktop windows to switch.
After selecting another window from the Window List,
`focus-out' is fired eventually too.

So when `focus-in' is not ignored in avoid.el then the
mouse cursor will be moved after showing the Window List.
But it seems this is not a problem because special mouse
processing is disabled when the Window List is shown.

> Wouldn't you want the mouse moved when you are about to type?

Yes, it's better to move the mouse on focusing in
than later on typing a key after switching.

Message #14 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Sat, 10 May 2014 09:16:33 +0300

> From: Juri Linkov <juri <at> jurta.org>
> Cc: 17439 <at> debbugs.gnu.org
> Date: Fri, 09 May 2014 23:35:20 +0300
> 
> > Why did you add focus-in as well?
> 
> When I tried to switch out with
> 
> (defun test () (message "%S" last-input-event))
> (setq timer (run-with-idle-timer 0.1 t 'test))
> 
> it prints to *Messages* both lines:
> 
> (focus-in #<frame emacs <at> localhost 0x1121908>)
> (focus-out #<frame emacs <at> localhost 0x1121908>)
> 
> `focus-in' is fired by the desktop window switcher
> that shows the list of desktop windows to switch.
> After selecting another window from the Window List,
> `focus-out' is fired eventually too.
> 
> So when `focus-in' is not ignored in avoid.el then the
> mouse cursor will be moved after showing the Window List.
> But it seems this is not a problem because special mouse
> processing is disabled when the Window List is shown.
> 
> > Wouldn't you want the mouse moved when you are about to type?
> 
> Yes, it's better to move the mouse on focusing in
> than later on typing a key after switching.

So are you saying we should NOT ignore focus-in?  If you still think
focus-in should be ignored, then I think the above description
(perhaps together with the window manager where it was observed)
should be in the comments to the code.

Thanks.

Message #17 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Sat, 10 May 2014 23:38:20 +0300

> So are you saying we should NOT ignore focus-in?  If you still think
> focus-in should be ignored, then I think the above description
> (perhaps together with the window manager where it was observed)
> should be in the comments to the code.

After more testing without ignoring focus-in and with ignoring focus-out,
often pressing and releasing Alt-Tab quickly generates both events
focus-in and focus-out, and when having no time to show the Window List
focus-in moves the mouse pointer and hides the selected window.
So both events should be ignored, like `switch-frame' is already ignored
when switching between Emacs frames.  I'll add a comment about this.

And there are more fixes necessary in avoid.el.  This patch will ignore
modifiers used together with mouse events:

=== modified file 'lisp/avoid.el'
--- lisp/avoid.el	2014-01-01 07:43:34 +0000
+++ lisp/avoid.el	2014-05-10 20:36:19 +0000
@@ -347,7 +348,13 @@ (defun mouse-avoidance-ignore-p ()
 		   (memq 'double modifiers)
 		   (memq 'triple modifiers)
 		   (memq 'drag modifiers)
-		   (memq 'down modifiers)))))))
+		   (memq 'down modifiers)
+		   (memq 'meta modifiers)
+		   (memq 'control modifiers)
+		   (memq 'shift modifiers)
+		   (memq 'hyper modifiers)
+		   (memq 'super modifiers)
+		   (memq 'alt modifiers)))))))
 
 (defun mouse-avoidance-banish ()
   (if (not (mouse-avoidance-ignore-p))

And this patch fixes the customization of `mouse-avoidance-banish-position'
(it can be tested by e.g. using `set-variable' on `mouse-avoidance-banish-position'):

=== modified file 'lisp/avoid.el'
--- lisp/avoid.el	2014-01-01 07:43:34 +0000
+++ lisp/avoid.el	2014-05-10 20:36:19 +0000
@@ -129,9 +129,10 @@ (defcustom mouse-avoidance-banish-positi
 TOP-OR-BOTTOM-POS: Distance from top or bottom edge of frame or window."
   :group   'avoid
   :version "24.3"
-  :type    '(alist :key-type symbol :value-type symbol)
-  :options '(frame-or-window side (side-pos integer)
-             top-or-bottom (top-or-bottom-pos integer)))
+  :type    '(alist :key-type symbol :value-type (choice symbol integer))
+  :options '((frame-or-window symbol) (side symbol) (side-pos integer)
+             (top-or-bottom symbol) (top-or-bottom-pos integer)))

Message #20 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Sun, 11 May 2014 23:19:51 +0300

> So are you saying we should NOT ignore focus-in?  If you still think
> focus-in should be ignored, then I think the above description
> (perhaps together with the window manager where it was observed)
> should be in the comments to the code.

Actually, the root of the problem is `raise-frame' in
`mouse-avoidance-set-mouse-position' that brings
an Emacs frame back to the front after switching.

This is a better patch:

=== modified file 'lisp/avoid.el'
--- lisp/avoid.el	2014-01-01 07:43:34 +0000
+++ lisp/avoid.el	2014-05-11 20:15:17 +0000
@@ -177,7 +178,21 @@ (defun mouse-avoidance-set-mouse-position
   ;; difficult to do, so we just raise the frame to avoid frame switches.
   ;; Returns t if it moved the mouse.
   (let ((f (selected-frame)))
-    (raise-frame f)
+    (unless (and (consp last-input-event)
+		 (symbolp (car last-input-event))
+		 (memq (car last-input-event)
+		       '(
+			 ;; `run-with-idle-timer' generates the `focus-out'
+			 ;; event on switching out from the current frame,
+			 ;; but `raise-frame' brings the same frame back,
+			 ;; so ignore `focus-out' here.
+			 focus-out
+			 ;; Some window managers generate the `focus-in' event
+			 ;; when showing the Window List, but `raise-frame' forcibly
+			 ;; switches to an Emacs frame when the Window List is active,
+			 ;; so `focus-in' needs to be ignored here too.
+			 focus-in)))
+      (raise-frame f))
     (set-mouse-position f (car pos) (cdr pos))
     t))
 

Message #23 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Sun, 11 May 2014 17:06:32 -0400

> +    (unless (and (consp last-input-event)
> +		 (symbolp (car last-input-event))
> +		 (memq (car last-input-event)

Aka (unless (memq (car-safe last-input-event)

> +		       '(
> +			 ;; `run-with-idle-timer' generates the `focus-out'

Huh?  `run-with-idle-timer' is not supposed to generate any event.

> +			 ;; event on switching out from the current frame,
> +			 ;; but `raise-frame' brings the same frame back,
> +			 ;; so ignore `focus-out' here.
> +			 focus-out

Running mouse avoidance after focus-out does not seem very useful, so we
should filter out focus-out elsewhere than here.

> +			 ;; Some window managers generate the `focus-in' event
> +			 ;; when showing the Window List,

What means "showing the Window List"?

> +			 ;;  but `raise-frame' forcibly switches to an Emacs frame when the Window List is active,

I don't know what this is talking about either.

> +			 ;; so `focus-in' needs to be ignored here too.

Shouldn't `switch-frame' be ignored for similar reasons, then?


        Stefan

Message #26 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Mon, 12 May 2014 00:31:48 +0300

>> +    (unless (and (consp last-input-event)
>> +		 (symbolp (car last-input-event))
>> +		 (memq (car last-input-event)
>
> Aka (unless (memq (car-safe last-input-event)

This is what I thought about, but decided to keep
code consistency with `mouse-avoidance-ignore-p'.
But `mouse-avoidance-ignore-p' could be optimized too.

>> +		       '(
>> +			 ;; `run-with-idle-timer' generates the `focus-out'
>
> Huh?  `run-with-idle-timer' is not supposed to generate any event.

It runs on `focus-out', as this short test demonstrates:

(defun test () (message "%S" last-input-event))
(setq timer (run-with-idle-timer 0.1 t 'test))

It generates:

(focus-in #<frame emacs <at> localhost 0x1121908>)
(focus-out #<frame emacs <at> localhost 0x1121908>)

>> +			 ;; event on switching out from the current frame,
>> +			 ;; but `raise-frame' brings the same frame back,
>> +			 ;; so ignore `focus-out' here.
>> +			 focus-out
>
> Running mouse avoidance after focus-out does not seem very useful, so we
> should filter out focus-out elsewhere than here.

I'll move `focus-out' back to `mouse-avoidance-ignore-p'
to not move the mouse pointer on `focus-out'.

>> +			 ;; Some window managers generate the `focus-in' event
>> +			 ;; when showing the Window List,
>
> What means "showing the Window List"?

It depends on the desktop environment, but usually this is a list of windows
shown after typing Alt-Tab.

>> +			 ;;  but `raise-frame' forcibly switches to an Emacs frame when the Window List is active,
>
> I don't know what this is talking about either.

This is specific behavior observed at least in one window manager (Gnome 2),
where typing Alt-Tab shows the Window List and generates the `focus-in' event
in Emacs at the same time.

>> +			 ;; so `focus-in' needs to be ignored here too.
>
> Shouldn't `switch-frame' be ignored for similar reasons, then?

Currently `switch-frame' is ignored in `mouse-avoidance-ignore-p',
so the mouse pointer is not moved when `switch-frame' is generated
in a new frame after switching between Emacs frames.

But maybe it should be handled like `focus-in', i.e. also
to not ignore it in `mouse-avoidance-ignore-p' and to move
the mouse pointer after switching between Emacs frames.

Message #29 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Sun, 11 May 2014 18:29:19 -0400

>> Huh?  `run-with-idle-timer' is not supposed to generate any event.
> It runs on `focus-out',

It does.  But that doesn't mean that "`run-with-idle-timer' generates
the `focus-out'".  The `focus-out' event is generated by the
window-manager plus Emacs's C code in response to some situation such as
a user action.  And after execution of the command bound to `focus-out',
we run the idle timers.

> (defun test () (message "%S" last-input-event))
> (setq timer (run-with-idle-timer 0.1 t 'test))
> It generates:
> (focus-in #<frame emacs <at> localhost 0x1121908>)
> (focus-out #<frame emacs <at> localhost 0x1121908>)

Your code generates some output which mentions `focus-out' but it did
not generate those events.

>>> +			 ;; Some window managers generate the `focus-in' event
>>> +			 ;; when showing the Window List,
>> What means "showing the Window List"?
> It depends on the desktop environment, but usually this is a list of windows
> shown after typing Alt-Tab.

Then I still don't understand: why would Emacs get a focus-in event when
the window-manager shows the "Window List"?  I'd maybe expect
a focus-*out* event, since suddenly the focus might go from Emacs to the
Window List.

Or do you mean that Emacs gets a focus-in event when the user selects
an Emacs frame in the window manager's Window List (maybe even if that
selection is transient while looping through all windows)?

>>> +			 ;;  but `raise-frame' forcibly switches to an Emacs
>>> frame when the Window List is active,

Well, this behavior is a choice of the window-manager.  While I'm very
happy to call raise-frame less often (so I generally agree with the
direction of the patch), you could argue that this might be a bug in the
window-manager.

> This is specific behavior observed at least in one window manager (Gnome 2),
> where typing Alt-Tab shows the Window List and generates the `focus-in' event
> in Emacs at the same time.

OK, I think I understand.  Please make the comment a bit more clear
about the fact that the focus-in event might come even *while* (rather
than *when*) the "Window List thingy to select a window" is active.

> But maybe it should be handled like `focus-in', i.e. also
> to not ignore it in `mouse-avoidance-ignore-p' and to move
> the mouse pointer after switching between Emacs frames.

I don't have a strong opinion either way, but it seems like they
generally should be handled in the same way, since they occur in similar
circumstances (one being when you focus-in from another frame of the
same Emacs session, while the other is when you focus-in from some
other process).


        Stefan

Message #32 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Mon, 12 May 2014 23:39:23 +0300

>>>> + ;;  but `raise-frame' forcibly switches to an Emacs frame
>>>> when the Window List is active,
>
> Well, this behavior is a choice of the window-manager.  While I'm very
> happy to call raise-frame less often (so I generally agree with the
> direction of the patch), you could argue that this might be a bug in the
> window-manager.

raise-frame causes more trouble, e.g. when another application is
in full-screen mode, then they both fight for which of them should stay
on the top, so typing a key in Emacs re-raises the selected Emacs frame,
and then another application brings itself to the front.

A comment in `mouse-avoidance-set-mouse-position' explains its rationale:

  ;; Ideally, should check if X,Y is in the current frame, and if not,
  ;; leave the mouse where it was.  However, this is currently
  ;; difficult to do, so we just raise the frame to avoid frame switches.

But actually such check already exists in `mouse-avoidance-ignore-p':

	(not (eq (car (mouse-position)) (selected-frame)))

and the mouse pointer is not moved when it's outside of the selected frame.

So I really see no problems with this patch:

=== modified file 'lisp/avoid.el'
--- lisp/avoid.el	2014-01-01 07:43:34 +0000
+++ lisp/avoid.el	2014-05-12 20:31:28 +0000
@@ -52,9 +52,6 @@
 ;;
 ;; - Using this code does slow Emacs down.  "banish" mode shouldn't
 ;;   be too bad, and on my workstation even "animate" is reasonable.
-;;
-;; - It ought to find out where any overlapping frames are and avoid them,
-;;   rather than always raising the frame.
 
 ;; Credits:
 ;; This code was helped by all those who contributed suggestions,
@@ -172,12 +170,8 @@ (defun mouse-avoidance-point-position ()
 
 (defun mouse-avoidance-set-mouse-position (pos)
   ;; Carefully set mouse position to given position (X . Y)
-  ;; Ideally, should check if X,Y is in the current frame, and if not,
-  ;; leave the mouse where it was.  However, this is currently
-  ;; difficult to do, so we just raise the frame to avoid frame switches.
   ;; Returns t if it moved the mouse.
   (let ((f (selected-frame)))
-    (raise-frame f)
     (set-mouse-position f (car pos) (cdr pos))
     t))
 
@@ -342,7 +336,7 @@ (defun mouse-avoidance-ignore-p ()
 	     (let ((modifiers (event-modifiers (car last-input-event))))
 	       (or (memq (car last-input-event)
 			 '(mouse-movement scroll-bar-movement
-			   select-window switch-frame))
+			   select-window focus-out))
 		   (memq 'click modifiers)
 		   (memq 'double modifiers)
 		   (memq 'triple modifiers)
@@ -403,8 +403,6 @@ (defun mouse-avoidance-mode (&optional m
  * cat-and-mouse: Same as `animate'.
  * proteus: As `animate', but changes the shape of the mouse pointer too.
 
-Whenever the mouse is moved, the frame is also raised.
-
 \(See `mouse-avoidance-threshold' for definition of \"too close\",
 and `mouse-avoidance-nudge-dist' and `mouse-avoidance-nudge-var' for
 definition of \"random distance\".)"

Message #35 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juri Linkov <juri <at> jurta.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Tue, 13 May 2014 15:33:36 -0400

> raise-frame causes more trouble, e.g. when another application is
> in full-screen mode, then they both fight for which of them should stay
> on the top, so typing a key in Emacs re-raises the selected Emacs frame,
> and then another application brings itself to the front.

Again sounds like a bug in the window-manager.

> So I really see no problems with this patch:

If that works, then by all means go for it.


        Stefan

Message #40 received at 17439-done <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17439-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Wed, 21 May 2014 00:14:57 +0300

>> So I really see no problems with this patch:
>
> If that works, then by all means go for it.

Installed (found no problems after more testing).

Message #43 received at 17439 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: 17439 <at> debbugs.gnu.org
Subject: Re: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Wed, 21 May 2014 01:12:29 +0300

>>> So I really see no problems with this patch:
>>
>> If that works, then by all means go for it.
>
> Installed (found no problems after more testing).

While looking at the mouse-related items in etc/TODO
I noticed this in the section Bugs:

  **** (mouse-avoidance-mode 'banish) then minimize Emacs,
  will pop window back up on top of all others

I guess this is fixed now and can be removed from etc/TODO?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.