Bug 13263 - REGRESSION: Page scroll when selecting characters from candidate window (inputting foreign Language) by arrow buttons
Summary: REGRESSION: Page scroll when selecting characters from candidate window (inpu...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P1 Minor
Assignee: Nobody
URL:
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2007-04-02 23:00 PDT by Chung-hong Chan
Modified: 2007-06-29 01:54 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chung-hong Chan 2007-04-02 23:00:07 PDT
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)
Comment 1 Alexey Proskuryakov 2007-04-03 02:43:16 PDT
Confirmed with Kotoeri Hiragana.
Comment 2 Mark Rowe (bdash) 2007-04-03 06:18:25 PDT
<rdar://problem/5107538>
Comment 3 Oliver Hunt 2007-04-23 14:57:50 PDT
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
Comment 4 Adele Peterson 2007-04-23 16:47:49 PDT
Not Hiragana! :)

Committed revision 21052.
Comment 5 Chung-hong Chan 2007-04-29 20:01:48 PDT
In the latest nightly build of Webkit, (29-Apr) this bug resurfaced.

Comment 6 Adele Peterson 2007-04-29 20:26:57 PDT
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. 
Comment 7 Oliver Hunt 2007-05-09 20:29:57 PDT
Fix landed r21346
Comment 8 Oliver Hunt 2007-05-09 22:11:03 PDT
Nope that patch broke other things.
Comment 9 Oliver Hunt 2007-06-27 02:23:26 PDT
Fix landed in r23813
Comment 10 t.suwa 2007-06-28 09:20:29 PDT
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.

Comment 11 Oliver Hunt 2007-06-28 09:24:37 PDT
Can you try with the nightly as they should have fixed this problem.  If they haven't it is worrying.
Comment 12 t.suwa 2007-06-28 15:37:49 PDT
Yes, I tried nightly r23841 and r23861 that is from svn repository.

The problem is still reproduced. 
Comment 13 Oliver Hunt 2007-06-28 15:41:09 PDT
What IM are you using?
Comment 14 t.suwa 2007-06-28 16:20:23 PDT
I'm using AquaSKK.
http://sourceforge.jp/projects/aquaskk/

Comment 15 Oliver Hunt 2007-06-28 20:44:00 PDT
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)
Comment 16 t.suwa 2007-06-29 00:11:18 PDT
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.

Comment 17 Oliver Hunt 2007-06-29 00:54:12 PDT
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.
Comment 18 t.suwa 2007-06-29 01:54:47 PDT
I submitted the bug 14457. Thanks Oliver.