RESOLVED FIXED 81186
REGRESSION (r103859): Cannot write a word with Korean double consonant
https://bugs.webkit.org/show_bug.cgi?id=81186
Summary REGRESSION (r103859): Cannot write a word with Korean double consonant
holy.adreamer
Reported 2012-03-14 20:02:03 PDT
When trying to type a word like '깍', which is 'ㄲ+ㅏ+ㄱ', in a text field, it results to 'ㅏㄱ'. And a word like '샀', which is 'ㅅ+ㅏ+ㅆ', results to 'ㅆ'. (For information, ㄲ is type by 'Shift+ㄱ') It seems like double consonant cannot be combined, and disappears when typed with other vowel. It happens in every text fields in a web page. Safari version doesn't have this kind of problem. Thank you.
Attachments
A quick fix (just for your information) (1.74 KB, patch)
2012-03-21 21:39 PDT, Hironori Bono
mitz: review-
A quick fix v1 (applied a comment) (1.83 KB, patch)
2012-04-05 15:40 PDT, Hironori Bono
no flags
Alexey Proskuryakov
Comment 1 2012-03-14 23:24:43 PDT
Confirmed with nightly r108302 as a regression form Safari 5.1.3 on OS X Lion. Steps to reproduce: 1. Enable Hangul 2-set input method. 2. Type Shift+R, K, R in any editable field. Expected results: 깍 Actual results: ㅏㄱ
Alexey Proskuryakov
Comment 2 2012-03-14 23:25:05 PDT
Hironori Bono
Comment 3 2012-03-21 01:51:35 PDT
Greetings, When I bisected nightly builds, this issue started from r103870 (*1) on my Lion Mac running on VMWare Fusion 4. Is it possible for someone to double-check this bisection result? (*1) <r103870.dmg">http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r103870.dmg> (*2) <r103857.dmg">http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r103857.dmg> Regards, Hironori Bono (In reply to comment #1) > Confirmed with nightly r108302 as a regression form Safari 5.1.3 on OS X Lion. > > Steps to reproduce: > > 1. Enable Hangul 2-set input method. > 2. Type Shift+R, K, R in any editable field. > > Expected results: 깍 > Actual results: ㅏㄱ
Hironori Bono
Comment 4 2012-03-21 21:39:01 PDT
Created attachment 133184 [details] A quick fix (just for your information) Greetings, I have noticed this is a side-effect of r103859 today. To update status text, this change sends a fake mouse-move event when the keyboard status is changed, including when releasing a shift key while composing text. Unfortunately, this fake event confuses a Korean input method and it resets its marked text. Even though I have written a quick fix, it is just for your information and I'm not sure if it is a right fix. Neither do I have good ideas how to write layout tests for it. (It seems this fake event is invisible from JavaScript.) I wish it helps. Regards, Hironori Bono
holy.adreamer
Comment 5 2012-03-26 19:02:39 PDT
Hello, I'm currently using r112169, but I'm afraid to say that this issue is still existing. Thank you.
Alexey Proskuryakov
Comment 6 2012-03-26 19:47:05 PDT
That's correct, the bug hasn't been fixed yet.
Hironori Bono
Comment 7 2012-04-04 11:24:47 PDT
Comment on attachment 133184 [details] A quick fix (just for your information) Greetings, I would like to set r? to my change to get interest of WebKit reviewers. (I wonder if it is good to stall this issue.) Regards, Hironori Bono
mitz
Comment 8 2012-04-04 11:40:42 PDT
Comment on attachment 133184 [details] A quick fix (just for your information) It looks like the problem is that the fake mouse event goes through mouseMovedInternal:, which does [[self inputContext] handleEvent:theEvent]. Since we don’t need the extra handling in -mouseMoved:, I think -postFakeMouseMovedEventForFlagsChangedEvent: should just change to do NativeWebMouseEvent webEvent(fakeEvent, self); _data->_page->handleMouseEvent(webEvent);
Hironori Bono
Comment 9 2012-04-05 15:40:00 PDT
Created attachment 135918 [details] A quick fix v1 (applied a comment) Greetings, Many thanks for your review and investigation. I have tested your solution and verified it also fixes this issue. Even though I do not have any ideas how to write a layout test for this issue, would it be possible to review the updated one? Regards, Hironori Bono (In reply to comment #8) > (From update of attachment 133184 [details]) > It looks like the problem is that the fake mouse event goes through mouseMovedInternal:, which does [[self inputContext] handleEvent:theEvent]. Since we don’t need the extra handling in -mouseMoved:, I think -postFakeMouseMovedEventForFlagsChangedEvent: should just change to do > > NativeWebMouseEvent webEvent(fakeEvent, self); > _data->_page->handleMouseEvent(webEvent);
mitz
Comment 10 2012-04-05 16:23:09 PDT
Comment on attachment 135918 [details] A quick fix v1 (applied a comment) Thanks for fixing this!
WebKit Review Bot
Comment 11 2012-04-06 17:14:25 PDT
Comment on attachment 135918 [details] A quick fix v1 (applied a comment) Clearing flags on attachment: 135918 Committed r113523: <http://trac.webkit.org/changeset/113523>
WebKit Review Bot
Comment 12 2012-04-06 17:14:33 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.