Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 104296

Summary:	kinput2 inoperative after Candidate Selection window move
Product:	Red Hat Enterprise Linux 3	Reporter:	Warren Togami <wtogami>
Component:	kinput2	Assignee:	Akira TAGOH <tagoh>
Status:	CLOSED WONTFIX	QA Contact:	Bill Huang <bhuang>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	eng-i18n-bugs
Target Milestone:	---	Keywords:	i18n
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-10-11 04:54:44 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 Warren Togami 2003-09-12 08:53:56 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
kinput2 mysteriously becomes inoperative if you click on a character choice
within the Candidate Selection dialog after you have dragged that dialog window.
 If you never click & drag the Candidate Selection dialog, it works fine.  

Unfortunately due to the annoying problems of gtk2 apps like Bug 84860 and Bug
84859 where the candidate selection window appears below the bottom left of the
window rather than under the text input, it is guaranteed that the user will
click & drag the kinput2 Candidate Selection dialog, triggering this bug.

Version-Release number of selected component (if applicable):
kinput2-canna-wnn6-v3.1-10

How reproducible:
Always

Steps to Reproduce:

1. SHIFT-SPACE
2. nihongo
3. SPACE SPACE
4. Click and move Candidate Selection window anywhere.
5. Click on &#26085;&#26412;&#35486;  (the far left choice)

Actual Results:  
kinput2 seems to no longer respond.  Western character input continues to work
in gedit, but within Mozilla keyboard input behaves strangely and unable to
enter western characters.

Expected Results:  
It should not render kinput2 inoperative.

Comment 1 Akira TAGOH 2003-09-16 07:54:55 UTC

It looks like similar bug with Bug#78017. and I can't reproduce this except gtk2
applications.

Comment 2 Warren Togami 2004-01-28 10:14:59 UTC

Hmm, this sometimes causes kinput2 to fail totally and consume 100%
CPU.  Sometimes it fails completely only after several tries only in
that individual application, and subsequently works again if you
restart that application (like gedit).

Comment 3 Warren Togami 2004-01-28 10:24:04 UTC

When it got stuck at 100% CPU usage, strace kept repeating this in a
seemingly infinite loop:

--- SIGPIPE (Broken pipe) @ 0 (0) ---
select(6, [4 5], [], [], {0, 0})        = -1 EBADF (Bad file descriptor)
getuid32()                              = 500
geteuid32()                             = 500
getuid32(

kill failed to kill it.  It took kill -9 to stop it.

Comment 4 Akira TAGOH 2004-01-29 07:55:12 UTC

I suspect it's maybe another bug but it's just triggered by this.
Could you please submit it as another bug and mention the sure way to
reproduce the problem?

Comment 5 Warren Togami 2004-02-04 00:23:26 UTC

Yes, I think the 100% CPU usage and kill -9 problem is a separate bug.
 Maybe Bug #114886.

Comment 6 Warren Togami 2004-10-21 10:38:03 UTC

This is no longer imperative for FC3/RHEL4 as IIIMF is the preferred
input method.  Please verify that this is not an issue for RHEL3
customers.

Comment 7 Leon Ho 2006-10-11 04:54:44 UTC

WONTFIX in RHEL3 Updates.