From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.bugs Subject: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Date: Tue, 3 Oct 2017 20:15:53 -0400 Message-ID: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11404ff69685c0055aad840b" X-Trace: blaine.gmane.org 1507076233 1465 195.159.176.226 (4 Oct 2017 00:17:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2017 00:17:13 +0000 (UTC) Cc: 28620@debbugs.gnu.org To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 04 02:17:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzXN4-0007yK-Px for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Oct 2017 02:17:07 +0200 Original-Received: from localhost ([::1]:60757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzXNC-0003Uo-2n for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Oct 2017 20:17:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44763) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzXN5-0003Uf-CW for bug-gnu-emacs@gnu.org; Tue, 03 Oct 2017 20:17:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzXN0-0002lr-AS for bug-gnu-emacs@gnu.org; Tue, 03 Oct 2017 20:17:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38369) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dzXN0-0002le-6h for bug-gnu-emacs@gnu.org; Tue, 03 Oct 2017 20:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dzXN0-0007Mc-0p for bug-gnu-emacs@gnu.org; Tue, 03 Oct 2017 20:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Weiner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Oct 2017 00:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28620-submit@debbugs.gnu.org id=B28620.150707619727012 (code B ref 28620); Wed, 04 Oct 2017 00:17:01 +0000 Original-Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 00:16:37 +0000 Original-Received: from localhost ([127.0.0.1]:47050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzXMa-00071F-Ik for submit@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzXMY-0006vY-SA for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzXMO-00027F-Oz for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:29 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46182) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzXMO-00026w-Kv for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:24 -0400 Original-Received: from mail-qt0-f172.google.com ([209.85.216.172]:48675) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzXMO-0006j4-92 for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:24 -0400 Original-Received: by mail-qt0-f172.google.com with SMTP id d13so15605330qta.5 for <28620@debbugs.gnu.org>; Tue, 03 Oct 2017 17:16:24 -0700 (PDT) X-Gm-Message-State: AMCzsaVKFDhDcjlnLX9Tng8yUTtahOqwo2GahRTn0N41d7UapdPLUZtw QJo401J8jdsMlZjwdRFkPLOcZiowqpPtQxBNUoQ= X-Google-Smtp-Source: AOwi7QCO/kFGH5Om2FJ5lgs9Z6LLA4vHEhxbnytuxIeJN7N4t5/u+17OVQcHq360BXjDfmUsi4xHc5FII2j5jFklTDY= X-Received: by 10.200.34.167 with SMTP id f36mr25633144qta.173.1507076183850; Tue, 03 Oct 2017 17:16:23 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 17:15:53 -0700 (PDT) In-Reply-To: <20171003224017.GA51637@breton.holly.idiocy.org> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:137865 Archived-At: --001a11404ff69685c0055aad840b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 3, 2017 at 6:40 PM, Alan Third wrote: > On Tue, Oct 03, 2017 at 02:21:43PM -0400, Robert Weiner wrote: > > This happens consistently in testing. This must be a bug in > mouse-position > > for macOS, right? Why would (mouse-position) still report f1 when f2 i= s > > the selected frame? Maybe this is why I am seeing the wrong frame on > drag > > releases too. > > As far as I can tell ns_mouse_position returns the frame stored in > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however: > > If the user clicks a view that isn=E2=80=99t in the key window, by de= fault > the window is brought forward and made key, but the mouse event is > not dispatched. > =E2=80=8BWhat does "the mouse event is not dispatched mean"? Does it mean = Emacs never sees the event? Maybe Emacs sees only that the window has been selected by the window manager and based on that switches to the selected window of the frame? > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > https://developer.apple.com/library/content/documentation/ > Cocoa/Conceptual/EventOverview/HandlingMouseEvents/ > HandlingMouseEvents.html > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > My guess is that ns_mouse_position needs to get a list of NSWindows, > =E2=80=8B=E2=80=8B > iterate over them to find out which one the mouse pointer is over, > =E2=80=8B=E2=80=8B > convert that NSWindow back to an Emacs frame, and set *fp to it before > =E2=80=8B=E2=80=8B > returning. > =E2=80=8BThe mouse wheel code manages to scroll the proper window that the = mouse is over, even across overlapping frames where the window the mouse is over is in a frame that is partially behind another frame. And this happens without without any click events. This could be utilized in the click event code to get this right somehow. It looks like the EV_TRAILER macro call at the end of the nsterm.c mouseDown function (which is also called by mouseUp) sets the frame used for mouse button down, up and scroll wheel events from the variable emacsframe. Somehow the value of emacsframe must be set differently for mouse up events than it is for mouse wheel events since they end up with different frames for the same mouse positions. Bob --001a11404ff69685c0055aad840b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 3, 20= 17 at 6:40 PM, Alan Third <ala= n@idiocy.org> wr= ote:
=
On Tue, Oct 03, 2017 at 02:21:43PM -0400, Ro= bert Weiner wrote:
> This happens consistently in testing.=C2=A0 This must be a bug in mous= e-position
> for macOS, right?=C2=A0 Why would (mouse-position) still report f1 whe= n f2 is
> the selected frame?=C2=A0 Maybe this is why I am seeing the wrong fram= e on drag
> releases too.

As far as I can tell ns_mouse_position returns the frame stored in
dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however= :

=C2=A0 =C2=A0 If the user clicks a view that isn=E2=80=99t in the key windo= w, by default
=C2=A0 =C2=A0 the window is brought forward and made key, but the mouse eve= nt is
=C2=A0 =C2=A0 not dispatched.

=E2=80=8BWhat does= "the mouse event is not dispatched mean"?=C2=A0 Does it mean Ema= cs never sees the event?=C2=A0 Maybe Emacs sees only that the window has be= en selected by the window manager and based on that switches to the selecte= d window of the frame?
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://developer.apple.com/library/content/docum= entation/Cocoa/Conceptual/EventOverview/HandlingMouseEvents/= HandlingMouseEvents.html
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
My guess is that ns_mouse_position needs= to get a list of NSWindows,
=E2=80=8B=E2=80=8B
iterate over them to find out which one = the mouse pointer is over,
=E2=80=8B=E2=80=8B
convert that NSWindow back to an Emacs f= rame, and set *fp to it before
=E2=80=8B=E2=80=8B
returning.

= =E2=80=8BThe mouse wheel code manages to scroll the proper window that the = mouse is over, even across overlapping frames where the window the mouse is= over is in a frame that is partially behind another frame.=C2=A0 And this = happens without without any click events.=C2=A0 This could be utilized in t= he click event code to get this right somehow.

It looks like the EV_= TRAILER macro call at the end of the nsterm.c mouseDown function (which is = also called by mouseUp) sets the frame used for mouse button down, up and s= croll wheel events from the variable emacsframe.=C2=A0 Somehow the value of= emacsframe must be set differently for mouse up events than it is for mous= e wheel events since they end up with different frames for the same mouse p= ositions.

Bob

--001a11404ff69685c0055aad840b--