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

Previous Next

Package: emacs;

Reported by: rswgnu <at> gmail.com

Date: Wed, 27 Sep 2017 15:45:01 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Robert Weiner <rsw <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28620 <at> debbugs.gnu.org
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
Date: Tue, 3 Oct 2017 14:53:07 -0400
[Message part 1 (text/plain, inline)]
On Tue, Oct 3, 2017 at 2:42 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Robert Weiner <rsw <at> gnu.org>
> > Date: Tue, 3 Oct 2017 14:21:43 -0400
> > Cc: Eli Zaretskii <eliz <at> gnu.org>
> >
> > I start with the mouse within a window of f1 and selected frame of f1;
> (mouse-position) also reports f1.
> >
> > I click mouse-1 in an Emacs window of f2 and leave it there.
> > (selected-frame) is now f2
> > macOS window manager highlights f2 as active window
> > (frame-focus) returns nil
> > (mouse-position) reports a frame of f1 <<< WRONG
>
> Sounds like something that's macOS specific.  At least on MS-Windows I
> cannot reproduce this: mouse-position returns the correct frame.
>

​Ok, that is good to know.  Is there a go to person for the Mac-specific
windowing code to check on this with?

Could someone check when running X with a click-for-focus window manager
setting and see what happens there?

Bob
[Message part 2 (text/html, inline)]

This bug report was last modified 4 years and 333 days ago.

Previous Next


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