GNU bug report logs - #28620
Mouse drag event records wrong window for release when crossing frames

Previous Next

Full log

View this message in rfc822 format

From: Bob Weiner <rsw <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 28620 <at> debbugs.gnu.org
Subject: bug#28620: Emacs bug#28620: (PARTIAL SOLUTION) mouse-position wrong on macOS and Windows 7 after mouse-1 click
Date: Mon, 16 Oct 2017 11:11:33 -0400

Robert Weiner <rsw <at> gnu.org> writes:

I wrote:
>
> ​The issue, to recap, is that I can't find a function that
> will report the window that a mouse release button event
> occurs in if the depress and release are in different frames
> (for Emacs 25).
>
> In fact, the release event (drag event) contains the wrong
> frame (that of the depress rather than the release).  The wrong 
> frame is also reported by mouse-position and mouse-pixel-position,
> so window-at can't be used either.

The following is a temporary fix for the mouse-position and
mouse-pixel-position part of the problem.  Something needs to be fixed
in the original functions in the C code, though.  -- Bob

;; From mouse-position:
;;    f = SELECTED_FRAME ();
;;    XSETFRAME (lispy_dummy, f);
;;  It seems like the XSETFRAME macro is not properly copying the value of f on initial frame selection under the macOS window system.
;;  The problem occurs on other systems as well, e.g. Emacs 25.2 under Windows 7.
;;  The function below is a temporary fix for this.
(setq mouse-position-function
      (lambda (frame-x-dot-y)
	"Under macOS, mouse-position and mouse-pixel-position sometimes fail to return the selected-frame (returning the prior frame instead); fix that here."
	(setcar frame-x-dot-y (selected-frame))
	frame-x-dot-y))

Previous Next

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