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.
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: ㅏㄱ
<rdar://problem/11053232>
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: ㅏㄱ
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
Hello, I'm currently using r112169, but I'm afraid to say that this issue is still existing. Thank you.
That's correct, the bug hasn't been fixed yet.
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
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);
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);
Comment on attachment 135918 [details] A quick fix v1 (applied a comment) Thanks for fixing this!
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>
All reviewed patches have been landed. Closing bug.