Red Hat Bugzilla – Bug 112762
candidate window not visible with a maximized window
Last modified: 2007-11-30 17:10:34 EST
Description of problem:
With certain Japanese servers that display multiple candidates in a
window (Canna... FreeWnn usually displays the candidates one at a time
inline unless a control/function sequence is pressed), the candidate
window will not be visible, and will be underneath the gnome-panel.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open Mozilla in a default Japanese environment with Canna running
2. Maximize the mozilla window
3. Put focus in an input area like the URL area, turn on kinput
with Shift-Space, then type a romaji sequence in an input area
(such as "sushi"), press the space bar twice-- the first time to
convert, the second time to display alternate candidates.
The candidate window sometimes (especially the first time) appears
underneath the gnome-panel
The candidate window should be the top z-layer, with focus either
staying on the parent window or focus on the candidate window, and the
focus returning to the parent after a selection is chosen by pressing
The input status (the "[ ã ]" in the lower left corner) does always
stay on the top Z-layer, which is correct.
otaylor said that this is a general gtk problem. I think he indicated
that kinput2 itself needs to implement this functionality. Note that
it currently works with openoffice-1.1.0-24 and all qt apps, but not
mozilla and many other gtk2 apps.
It should be noted that IIIMF (on FC2t3) does not have this problem.
closing this fc1 bug as its fixed in latest versions