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

[Emacs bug Tracking System]

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

--- Begin Message --- Subject: 23.0.60; Emacs.app may process events in wrong window Date: Mon, 5 Jan 2009 21:57:42 +0100

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

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: Emacs.app may process events in wrong window
>
>
>
>
> Date: 
>
> Wed, 21 Jan 2009 21:00:02 +0200
>
>
>
>
> 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.
>
>
>
> --- End Message ---