Apache OpenOffice (AOO) Bugzilla – Issue 69051
scim hangul input and cursor keys
Last modified: 2011-02-10 10:44:25 UTC
So, I have a scenario where the single keyinput short-circuit for the input engine commit breaks for me. To reproduce. 1. activate scim, select "hangul" 2. type "gksrmf" you should have one commited character, and one highlighted "in progress" character. 3. press right arrow What happens for me, is that the last glyph "disappears" and doesn't get set into the document, but I see that it is sent to the document through the doKeyCallback shortcut for a single unicode character. So, what I see as the sequence of events that OOo receives here when the right arrow is pressed is... 1. OOo gets "right-arrow" key event from gtk in GtkSalFrame::signalKey and adds it to m_nPrevKeyPresses 2. OOo gets "buffer commit" event from gtk, it falls into the single character condition, and checks to see what key is at the top of m_nPrevKeyPresses and reuses it's keycode (which is arrow) 3. writer gets an arrow keycode, but with "unicode character from buffer" value 4. but writer processes it as an arrow, so the character disappears from the screen 5. back in vcl, the real arrow key get processed 6. writer gets arrow keycode, normal arrow processing Now, on my x86_64 box I actually have a *different* sequence 1. OOo gets "buffer commit" event from gtk, either 1.a.1 m_nPrevKeyPresses is empty and the short-circuit is not used OR 1.b.1 falls into the single character condition, and checks to see what key is at the top of m_nPrevKeyPresses and reuses it's keycode "foo"[1] 1.b.2 writer gets an "foo" keycode, but with "unicode character from buffer" value 1.b.3 writer processes it as a character insertion, and use unicode character, all is well 2. OOo gets "right-arrow" key event from gtk in GtkSalFrame::signalKey, and stuff progress as normal [1] where foo != right arrow, as right arrow hasn't been seen yet. But foo generally seems a fairly arbitrary letter from the past. e.g. holding down a letter long enough to repeat the letter will generate multiple press events and thus add multiple characters to m_nPrevKeyPresses, but releasing it will generate one single release event and only pop one event from m_nPrevKeyPresses. Perhaps there is a simple fix here. or some race condition. Or the problem lies in the input engine. But the keypresses stuff seems unreliable. What about the following alternative hack patch? Too naive ?
Created attachment 38820 [details] possible patch
Omitting the whole key release swallow stuff could break those input methods that do not swallow those events. However there was a patch in CWS vcl64 to send key release events also through gtk_im_context_filter_keypress (which is wrongly named and was documented wrong), please try whether that fixes the problem already; this should be the case if hangul properly filters the release events corresponding to the key presses. The relevant gtkframe.cxx version would be 1.52 and newer
unfortunately this is with OOD680_m2 which has that workspace integrated into it :-(, perhaps this could be described as a problem in this particular hangul input engine, but I'm also worried about stuff like holding down e.g. f for a few seconds which seems to generates multiple gtk key-press events but only one key-release event, so logic based on whether the backbuffer of keypresses is empty or not seems a little dodgy.
I don't see how m_aPrevKeyPresses can be empty in the commit callback: you should only be able to come here via gtk_im_context_filter_keypress, that is while still being in handleKeyEvent. The only way this could happen is that an IM "eats" an event but actually returns "false" in gtk_im_context_filter_keypress, this would lead to handleKeyEvent popping an event from the stack falsely. The m_aPrevKeyPresses.empty() in signalCommit is actually just a sanity check to avoid accessing an empty list in weird conditions. BTW: the single key handling is just a workaround itself; many controls do not handle extended text input and therefore rely on corresponding key events - including by the way on the modifier state which cannot be determined without a key event. I guess that normally these would not get filtered, but i would not necessarily want to rely on that thinking of the many many input methods we're talking here. However this leaves us with a key event (cursor right in this case), which gets a "replaced" unicode by the IM, certainly a valid case, which is not handled well currently. As immediate measure i think we could change CheckSingleKeyCommitHack so it would return false for gdk keyvals that do not correspond to a unicode (like cursor keys, function keys, etc.) What's your opinion ?
Actually i have problems reproducing the problem (which probably just shows that one cannot trust input methods very far :-) ). Does the following patch solve the problem for you ?
Created attachment 39078 [details] proposed patch for gtkframe.cxx
Hmm, it looks like at least part of this, and possibly all of this, is the ordering that gtk gets to process events fired from the IM. i.e. this is with scim-bridge and gtk, and at least under some circumstances (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206261) some key events will be delivered to the app out of the intended sequence, so it's pointless to address any possible remaining problems with e.g. the hangul IM until the event ordering is reliable.
changing target, i guess if there need to be fixes in gtk this won't make it into 2.1
adjusting target due to limited resources
*** Issue 75040 has been marked as a duplicate of this issue. ***
still cannot reproduce the problem I guess this one died of old age
closing