Bug 81186 - REGRESSION (r103859): Cannot write a word with Korean double consonant
Summary: REGRESSION (r103859): Cannot write a word with Korean double consonant
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.7
: P1 Critical
Assignee: Nobody
URL:
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2012-03-14 20:02 PDT by holy.adreamer
Modified: 2012-04-06 17:14 PDT (History)
7 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description holy.adreamer 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.
Comment 1 Alexey Proskuryakov 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: ㅏㄱ
Comment 2 Alexey Proskuryakov 2012-03-14 23:25:05 PDT
<rdar://problem/11053232>
Comment 3 Hironori Bono 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: ㅏㄱ
Comment 4 Hironori Bono 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
Comment 5 holy.adreamer 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.
Comment 6 Alexey Proskuryakov 2012-03-26 19:47:05 PDT
That's correct, the bug hasn't been fixed yet.
Comment 7 Hironori Bono 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
Comment 8 mitz 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);
Comment 9 Hironori Bono 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);
Comment 10 mitz 2012-04-05 16:23:09 PDT
Comment on attachment 135918 [details]
A quick fix v1 (applied a comment)

Thanks for fixing this!
Comment 11 WebKit Review Bot 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>
Comment 12 WebKit Review Bot 2012-04-06 17:14:33 PDT
All reviewed patches have been landed.  Closing bug.