Bug 13263 – REGRESSION: Page scroll when selecting characters from candidate window (inputting foreign Language) by arrow buttons

• Component: Text
• Status: RESOLVED FIXED

[Chung-hong Chan]

Overview: 
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

Actual results: 
Page scroll together with candidate window "page down"

Expected results:
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
Camino 1.03
Safari 2 (shipping build on Mac OS X 10.4.8)

[Alexey Proskuryakov]

Confirmed with Kotoeri Hiragana.

[Mark Rowe (bdash)]

<rdar://problem/5107538>

[Oliver Hunt]

From radar:
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

[Adele Peterson]

Not Hiragana! :)

Committed revision 21052.

[Chung-hong Chan]

In the latest nightly build of Webkit, (29-Apr) this bug resurfaced.

[Adele Peterson]

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. 

[Oliver Hunt]

Fix landed r21346

[Oliver Hunt]

Nope that patch broke other things.

[Oliver Hunt]

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.

[Oliver Hunt]

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. 

[Oliver Hunt]

What IM are you using?

I'm using AquaSKK.
http://sourceforge.jp/projects/aquaskk/

[Oliver Hunt]

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".

Actual results:
Select an ascii input mode(gray icon), insert undesired "l"

Expected results:
Select an ascii input mode, not insert "l".  You can see this behavior outside of HTML contents.

[Oliver Hunt]

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.