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

[Wolfgang Lux]

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.

nsterm.patch
Description: Binary data

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''