Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 104296 - kinput2 inoperative after Candidate Selection window move
Summary: kinput2 inoperative after Candidate Selection window move
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kinput2
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Bill Huang
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-12 08:53 UTC by Warren Togami
Modified: 2007-11-30 22:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-10-11 04:54:44 UTC
Target Upstream Version:

Attachments (Terms of Use)

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

How reproducible:

Steps to Reproduce:

2. nihongo
4. Click and move Candidate Selection window anywhere.
5. Click on 日本語  (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

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

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

Comment 7 Leon Ho 2006-10-11 04:54:44 UTC
WONTFIX in RHEL3 Updates.

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