Bug 172011 - first keyboard/scroll event after cut misplaced
first keyboard/scroll event after cut misplaced
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Chip Coldwell
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-28 22:40 EDT by Joe Harrington
Modified: 2008-02-12 19:27 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-12 19:27:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Joe Harrington 2005-10-28 22:40:13 EDT
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):
emacs-21.3-21.FC3

How reproducible:
Always

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-28 22:43:04 EDT
If you cut/copy from a gterm window, the behavior is normal, as it is if there
is nothing cut/copied.

--jh--
Comment 2 Jens Petersen 2005-11-21 23:03:02 EST
In which Emacs frame is point (the cursor) active when this happens?
Comment 3 Joe Harrington 2005-12-19 16:12:19 EST
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?

--jh--
Comment 4 Jens Petersen 2006-02-03 03:19:40 EST
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-12 19:27:06 EST
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.