Bug 172011 - first keyboard/scroll event after cut misplaced
Summary: first keyboard/scroll event after cut misplaced
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Chip Coldwell
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-10-29 02:40 UTC by Joe Harrington
Modified: 2008-02-13 00:27 UTC (History)
0 users

Clone Of:
Last Closed: 2008-02-13 00:27:06 UTC

Attachments (Terms of Use)

Description Joe Harrington 2005-10-29 02:40:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Galeon/1.3.21

Description of problem:
With follow-pointer focus, when using 2 frames (separate X windows) in the same emacs session, the first keystroke or mouse scroll-wheel action after an X-window cut or copy can go into the wrong frame.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. emacs &
2. C-x 5 2 to start a second frame
3. put some text in the leftmost emacs window
4. cut or copy some of that text
5. move the mouse through the other emacs window and back to the first
   (or to a third emacs frame in the same session)
6. type or use the mouse scroll wheel to scroll

Actual Results:  The first character typed, or the first scrolling X event, go to the frame that was passed through, not the one that had focus (according to titlebar highlight).  Subsequent characters/scroll event go to the correct window.

Expected Results:  All events should go to the frame that had focus.

Additional info:

Behavior is the same on 2 FC3 systems that are fully updated.  This behavior has been around several years.  I am running metacity under gnome with "select windows when the mouse moves over them" focus.

Comment 1 Joe Harrington 2005-10-29 02:43:04 UTC
If you cut/copy from a gterm window, the behavior is normal, as it is if there
is nothing cut/copied.


Comment 2 Jens Petersen 2005-11-22 04:03:02 UTC
In which Emacs frame is point (the cursor) active when this happens?

Comment 3 Joe Harrington 2005-12-19 21:12:19 UTC
Sorry for the delay in replying.  The point is active in the active frame
(window manager title bar is highlit), where the mouse is.  The character typed
goes into an inactive buffer in the inactive frame.

Does your question indicate that you cannot reproduce the behavior?


Comment 4 Jens Petersen 2006-02-03 08:19:40 UTC
Sorry for slow response.

After "C-x 5 2" aren't the two frames displaying the same buffer?

I don't seem able to reproduce this on a rawhide box (post FC5test2),
but perhaps I'm missing something.

Comment 6 petrosyan 2008-02-13 00:27:06 UTC
Fedora Core 3 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

Note You need to log in before you can comment on or make changes to this bug.