When inputing foreign lanuage by Mac OS X built-in input methods (e.g. Jianyi, a Chinese input method) in text field of any webpage, when the candidate window pop-up and selecting character by arrow key on keyboard, page scroll.
Steps to reproduce:
1. View any webpage with text field and that webpage is long enough to scroll. Enter bug page in Bugzilla is a good example.
2. Click the text field. Select Jianyi input method (need to activate in International system pref.)
3. Open the perferences of Jianyi, select "candidate window" tab, select "Horizontal" window direction
4. input a two key-combination, e.g. nw. Should pop up a candidate window with some Chinese characters. use arrow key down to "page down" the candidate window
Page scroll together with candidate window "page down"
Candidate window "page down" without page scroll
Build Date & Platform:
Apr-3 2007, Mac OS X 10.4.8
Additional Builds and Platforms:
- Dosen't occur in
Safari 2 (shipping build on Mac OS X 10.4.8)
Confirmed with Kotoeri Hiragana.
When calling interpretKeyEvent we are somehow missing the fact that the arrow keys have been processed.
This results in us passing the key event to the system input manager twice. This means that we
* move up/down two elements in the candidate window on a single key press
* scroll the view, possibly due to the even being passed to the root webview
This effects any language that uses a candidate window during input
Not Hiragana! :)
Committed revision 21052.
In the latest nightly build of Webkit, (29-Apr) this bug resurfaced.
Yes, we had to roll this fix out. We were assuming that if interpretKeyEvents does not callback with insertText or doCommandBySelector, that the input method has handled the key event.
Unfortunately, interpretKeyEvents also does not send any callbacks for some key bindings that don't map to anything (like cmd-option-apostrophe, which is used by Mail.app). So we were incorrectly assuming that the key command was being eaten by an input method.
We have to find a way to work around this and be able to tell the difference between a key command that's handled by an input method, and a key command that just doesn't map to anything.
Fix landed r21346
Nope that patch broke other things.
Fix landed in r23813
I'm afraid that the issue is not solved.
My IM can change an input mode by pressing a single key without updating active input area. The key event was handled by my IM correctly but this behavior did not make an insertText callback.
Therefore, WebKit sent the key event to my IM twice.
Can you try with the nightly as they should have fixed this problem. If they haven't it is worrying.
Yes, I tried nightly r23841 and r23861 that is from svn repository.
The problem is still reproduced.
What IM are you using?
I'm using AquaSKK.
Righto, i've installed AquaSKK, but don't know how to bring up the candidate window. As far as i can tell the behaviour differs from Kotoeri and ATOK which means i can't use any of my testcases.
Can you give step by step instructions on how to make the candidate window come up? (using roman/ascii characters)
I'm so sorry for my bad comments.
The trouble I reported at #10 is not relevant to the candidate window. However, I thought this depends on the bug 13263.
I guess that WebKit can't detect the IM's event consumption when IM eats the event silently and makes no visual feedbacks.
Steps to reproduce:
1. View any webpage with text field.
2. Click the text field. Select a hirakana input mode(orange icon).
3. Type lowercase "L".
Select an ascii input mode(gray icon), insert undesired "l"
Select an ascii input mode, not insert "l". You can see this behavior outside of HTML contents.
Righto, in that case can you file a separate bug, including the url for AquaSKK and those instructions.
I had a quick go at fixing it, but doing so destroyed many layout tests so it not a trivial extension to this particular bug even though it is related.
I submitted the bug 14457. Thanks Oliver.