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): kinput2-canna-wnn6-v3.1-11 How reproducible: sometimes 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. Actual results: The candidate window sometimes (especially the first time) appears underneath the gnome-panel Expected results: 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 Enter. Additional info: The input status (the "[ ã ]" in the lower left corner) does always stay on the top Z-layer, which is correct.
http://bugzilla.gnome.org/show_bug.cgi?id=66471 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