Bug 104296 - kinput2 inoperative after Candidate Selection window move
kinput2 inoperative after Candidate Selection window move
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kinput2 (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Akira TAGOH
Bill Huang
: i18n
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-12 04:53 EDT by Warren Togami
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-11 00:54:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2003-09-12 04:53:56 EDT
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 日本語  (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 03:54:55 EDT
It looks like similar bug with Bug#78017. and I can't reproduce this except gtk2
applications.
Comment 2 Warren Togami 2004-01-28 05:14:59 EST
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 05:24:04 EST
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 02:55:12 EST
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-03 19:23:26 EST
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 06:38:03 EDT
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 00:54:44 EDT
WONTFIX in RHEL3 Updates.

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