bug#1791: 23.0.60; Emacs.app may process events in wrong window

bug#1791: 23.0.60; Emacs.app may process events in wrong window

[Wolfgang Lux]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org  
mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

If Emacs.app is not the active application, events are always  
processed by the
front-most window of Emacs rather than the intended window. For  
instance, start
Emacs.app and create a new frame via Ctrl-X 5 b <Return>. There are  
now two
frames displaying buffers *GNU Emacs* (in the back) and *scratch* (in  
the front).
At this point activate, another application and click the close  
button of the
frame displaying the *GNU Emacs* buffer (i.e., the back one).  
Emacs.app will
close the window displaying the *scratch* buffer instead. The same  
happens when
dragging text. Thus, in the scenario above, bring Terminal.app or  
TextEdit.app
to the front and drag some text onto the *GNU Emacs* buffer (the back  
one). The
text will appear in the *scratch* buffer instead of the *GNU Emacs*.

The problem seems to be the EV_TRAILER macro in nsterm.m which sends  
events to
SELECTED_FRAME() (apparently, the front-most window of Emacs.app)  
when the
application is not active. I cannot imagine a reason for this code  
and have
attached the obvious patch to fix the bug.


[-- Attachment #2: nsterm.patch --]
[-- Type: application/octet-stream, Size: 868 bytes --]

Index: src/nsterm.m
===================================================================
RCS file: /sources/emacs/emacs/src/nsterm.m,v
retrieving revision 1.41
diff -u -r1.41 nsterm.m
--- src/nsterm.m	2 Jan 2009 18:58:52 -0000	1.41
+++ src/nsterm.m	5 Jan 2009 20:56:09 -0000
@@ -288,8 +288,7 @@
    methods.  Maybe it should even be a function.  */
 #define EV_TRAILER(e)                                         \
   {                                                           \
-  XSETFRAME (emacs_event->frame_or_window, [NSApp isActive] ? \
-             emacsframe : SELECTED_FRAME ());                 \
+  XSETFRAME (emacs_event->frame_or_window, emacsframe);       \
   if (e) emacs_event->timestamp = EV_TIMESTAMP (e);           \
   n_emacs_events_pending++;                                   \
   kbd_buffer_store_event_hold (emacs_event, q_event_ptr);     \

[-- Attachment #3: Type: text/plain, Size: 208 bytes --]



In GNU Emacs 23.0.60.1 (powerpc-apple-darwin8.11.0, NS apple- 
appkit-824.48)
  of 2009-01-05 on Onyx.local
Windowing system distributor `Apple', version 10.3.824
configured using `configure  '--with-ns''

bug#1791: marked as done (23.0.60; Emacs.app may process events in wrong window)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]


Your message dated Wed, 21 Jan 2009 21:00:02 +0200
with message-id <56208D0D-4A01-48DC-B227-3D55D4B0C827@gmail.com>
and subject line Re: Emacs.app may process events in wrong window
has caused the Emacs bug report #1791,
regarding 23.0.60; Emacs.app may process events in wrong window
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
1791: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1791
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 6076 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 1387 bytes --]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org  
mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

If Emacs.app is not the active application, events are always  
processed by the
front-most window of Emacs rather than the intended window. For  
instance, start
Emacs.app and create a new frame via Ctrl-X 5 b <Return>. There are  
now two
frames displaying buffers *GNU Emacs* (in the back) and *scratch* (in  
the front).
At this point activate, another application and click the close  
button of the
frame displaying the *GNU Emacs* buffer (i.e., the back one).  
Emacs.app will
close the window displaying the *scratch* buffer instead. The same  
happens when
dragging text. Thus, in the scenario above, bring Terminal.app or  
TextEdit.app
to the front and drag some text onto the *GNU Emacs* buffer (the back  
one). The
text will appear in the *scratch* buffer instead of the *GNU Emacs*.

The problem seems to be the EV_TRAILER macro in nsterm.m which sends  
events to
SELECTED_FRAME() (apparently, the front-most window of Emacs.app)  
when the
application is not active. I cannot imagine a reason for this code  
and have
attached the obvious patch to fix the bug.


[-- Attachment #2.1.2: nsterm.patch --]
[-- Type: application/octet-stream, Size: 868 bytes --]

Index: src/nsterm.m
===================================================================
RCS file: /sources/emacs/emacs/src/nsterm.m,v
retrieving revision 1.41
diff -u -r1.41 nsterm.m
--- src/nsterm.m	2 Jan 2009 18:58:52 -0000	1.41
+++ src/nsterm.m	5 Jan 2009 20:56:09 -0000
@@ -288,8 +288,7 @@
    methods.  Maybe it should even be a function.  */
 #define EV_TRAILER(e)                                         \
   {                                                           \
-  XSETFRAME (emacs_event->frame_or_window, [NSApp isActive] ? \
-             emacsframe : SELECTED_FRAME ());                 \
+  XSETFRAME (emacs_event->frame_or_window, emacsframe);       \
   if (e) emacs_event->timestamp = EV_TIMESTAMP (e);           \
   n_emacs_events_pending++;                                   \
   kbd_buffer_store_event_hold (emacs_event, q_event_ptr);     \

[-- Attachment #2.1.3: Type: text/plain, Size: 208 bytes --]



In GNU Emacs 23.0.60.1 (powerpc-apple-darwin8.11.0, NS apple- 
appkit-824.48)
  of 2009-01-05 on Onyx.local
Windowing system distributor `Apple', version 10.3.824
configured using `configure  '--with-ns''


[-- Attachment #3: Type: message/rfc822, Size: 2822 bytes --]

From: Adrian Robert <adrian.b.robert@gmail.com>
To: 1791-done@emacsbugs.donarmstrong.com
Cc: Wolfgang Lux <wolfgang.lux@gmail.com>
Subject: Re: Emacs.app may process events in wrong window
Date: Wed, 21 Jan 2009 21:00:02 +0200
Message-ID: <56208D0D-4A01-48DC-B227-3D55D4B0C827@gmail.com>

I have applied the patch (thanks!) and am closing the bug.

I *believe* the ![NSApp isActive] -> SELECTED_FRAME() was to address  
an issue with multi-tty, however I cannot find any problems now with  
the patch applied.  Hopefully it is simply that it is no longer needed.