Red Hat Bugzilla – Bug 172011
first keyboard/scroll event after cut misplaced
Last modified: 2008-02-12 19:27:06 EST
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):
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.
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.
If you cut/copy from a gterm window, the behavior is normal, as it is if there
is nothing cut/copied.
In which Emacs frame is point (the cursor) active when this happens?
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?
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.
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.