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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: rswgnu <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 
 Alan Third <alan <at> idiocy.org>, 28620 <at> debbugs.gnu.org
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
Date: Thu, 12 Oct 2017 10:05:52 +0200

> So if I have 2 frames, f1 and f2, and a Chrome web browser window that is
> atop f2, then if I drag from f1 into Chrome above f2, my drag release code
> reports that the release window is in f2 rather than nil, as it should be.
> I am on macOS which uses click to focus, so Emacs still gets the release
> event since Chrome has not been selected with a click.

I would call this a feature: f2 is probably the one meaningful target of
your operation at that screen position.

> Is there any way to deal with external window z-order layering such that
> one can tell within Emacs whether the topmost OS-level window at an
> absolute mouse position is an Emacs frame or not?

Not really.  Compositing window managers on X no more allow to track the
visibility of windows reliably.  So while we can discern the visibility
of our own (window manager) windows based on what we store in their
asscociated frames' 'visible' slots, we can't do that for windows of
other applications.  And processing whatever else XGetWindowAttributes
returns for another application's window might not be trivial either.

It should be possible to do what you want on Windows (where the debugger
also notifies you when an Emacs frame is obscured) though.

martin

Previous Next

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