WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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-
Details
Formatted Diff
Diff
A quick fix v1 (applied a comment)
(1.83 KB, patch)
2012-04-05 15:40 PDT
,
Hironori Bono
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/11053232
>
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.
Top of Page
Format For Printing
XML
Clone This Bug