Bug 172011

Summary:	first keyboard/scroll event after cut misplaced
Product:	[Fedora] Fedora	Reporter:	Joe Harrington <jhmail>
Component:	emacs	Assignee:	Chip Coldwell <coldwell>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-02-13 00:27:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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):
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-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.

--jh--

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?

--jh--

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.