bug#26104: 26.0.50; In Ubuntu, having mouse over other frame cause Alt key to produce a <switch-frame> event

[martin rudalics <rudalics@gmx.at>]

 > It should be noted that I don't know that actually moving the mouse
 > plays a role here. As long as the mouse cursor is over the other
 > frame, the issue happens, even if I don't actually move it. Setting
 > track-mouse doesn't make a difference.

‘yank-pop’ by itself does not query the mouse position so "pressing the
Alt key produces a <switch-frame> event" as you said earlier does not
describe what really happens.  Someone else must have changed
`last-command' to `switch-frame' and it would be essential to find out
who.  And, as a furthe clue, the event must have come from a mouse move
since according to "the mouse is positioned over the other frame" this
is the only thing you do in between ‘yank’ and ‘yank-pop’ and if you do
not move the mouse in between them the M-y succeeds.  Or am I missing
something?

Now a frame switch triggered by mouse movement can only occur on
behalf of two underlying processes:

(1) The "window system" when tracking the mouse pointer tells us that it
     has crossed an edge from (focus-out-hook, mouse-leave-buffer-hook)
     or to (focus-in-hook) one of our window system windows.

(2) Emacs itself is tracking the mouse via `track-mouse' or something
     the like.

As for (1) I mentioned these hooks because they would allow you to put a
function on them in order to track what triggers your `switch-frame'
event.  As for (2) you would have to find all users/callers of
`track-mouse', inject some extra code in it to track its use and
recompile/reevaluate the users.

Simple put some code there that beeps like

(add-hook 'focus-in-hook 'ding)

and look what's happening.

All this would enable you to find out who generates a switch-frame event
although your mouse movements were apparently innocuous enough to never
motivate such an insertion.  If and when you find out the reason of that
insertion, we might be able to try to (optionally) prevent it.

 > I think trying to figure out where the switch-frame actually gets
 > triggered is a good idea. It looks like I'm going to have to try doing
 > some serious spelunking (at least for me)! As I think you suggest, I
 > want to try to figure out what is getting sent by xwindows vs what is
 > being generated by emacs itself.

If the above approach is inusfficient we indeed might have to add some
extra code to make_lispy_switch_frame in order to find out what happens.
In that case you have to be able to build Emacs on your machine.

martin