1233998 - [Cocoa] Some syllables are discared when you type Hangul characters

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[blim]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151216175450

Steps to reproduce:

I installed Firefox of the latest version on Mac. When I type in Korean in the Firefox web address window,  I see Korean being written improperly.


Actual results:

Korean vowels and consonants are typed in a strange way. 


Expected results:

Try any other web browsers and see how Korean should be typed in.

Comment 1

[Makoto Kato [:m_kato]]

(In reply to blim from comment #0)
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0)
> Gecko/20100101 Firefox/43.0
> Build ID: 20151216175450
> 
> Steps to reproduce:
> 
> I installed Firefox of the latest version on Mac. When I type in Korean in
> the Firefox web address window,  I see Korean being written improperly.
> 
> 
> Actual results:
> 
> Korean vowels and consonants are typed in a strange way. 
> 
> 
> Expected results:
> 
> Try any other web browsers and see how Korean should be typed in.

Could you provide us exactly reproduce step and screen shot ?   I cannot reproduce this on 10.11 with korean input method that installed by OSX.

Comment 2

[doublejar]

This issue affects me as well. I could reproduce this on my OS X 10.11 with 2-Set Korean input method and latest Firefox version. One more thing I noticed is that it also affects Thunderbird.

User Agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0"
Build ID: "20160726073904"
OSX Version: 10.11.6

Steps to reproduce:

1. First activate "2-Set Korean" input method in OSX. 
To do this, go to system Keyboard Preferences -> Input Sources -> Add -> Korean -> 2-Set Korean.

2. In the Firefox address bar (or any text box on a website) type some Korean words using "2-Set Korean" input method. For example, "안녕하세요" (on QWERTY keyboard, it's done by typing "dkssudgktpdy").


Actual results:

When typing "안녕하세요", the result is "안ㅕ하요". Consonants in the beginning of a syllable are lost.


Expected results:

In another browser, i.e. chrome, typing "안녕하세요" shows properly.


Workaround:

If I open About Firefox window, then close it, the bug disappears and I could type 안녕하세요 normally in both Firefox and Thunderbird. Until I reboot the computer then the bug returns.

Comment 3

[Stephen A Pohl [:spohl]]

Do the steps in comment 2 help to reproduce this?

Comment 4

[Makoto Kato [:m_kato]]

Humm, I can reproduce this by comment #2, but this is first time only.  When moving focus to content, it works well, then this does not occur until rebooting system.  So it isn't critical.

Also, when occurring this, compositing state isn't drawn well (it is same as Safari.  Maybe this is OS or IM's issue).

Comment 5

[Makoto Kato [:m_kato]]

Root cause may be IME bug.  Since IME doesn't send/call setMarkedText, we cannot detect whether current is composing.  And we cannot generate composition event when this occurs.  So I have to check this on 10.12.

Also, as long as I check drawn text on textbox on Safari, composing text isn't drawn correctly on Safari when this occur.  So, this will be same even if Safari.  (Safari can input text, but composing state isn't drawn correctly)

If this is 2nd process that IME uses, IME will send/call setMarkedText, so this doesn't occur.  It means that content process can send/post composition event if this occurs on address bar.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

This may still be affecting current versions, it's marked as affecting 53 in the duplicate bug 1300396. Too late for a fix for 53. Looks like this is part of the general backlog.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Moving all open keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I cannot reproduce this bug even immediately after restarting macOS (I tested with Catalina). How about you, guys?

(In reply to Makoto Kato [:m_kato] from comment #5)

Root cause may be IME bug. Since IME doesn't send/call setMarkedText, we
cannot detect whether current is composing. And we cannot generate
composition event when this occurs. So I have to check this on 10.12.

Also, as long as I check drawn text on textbox on Safari, composing text
isn't drawn correctly on Safari when this occur. So, this will be same even
if Safari. (Safari can input text, but composing state isn't drawn
correctly)

If this is 2nd process that IME uses, IME will send/call setMarkedText, so
this doesn't occur. It means that content process can send/post composition
event if this occurs on address bar.

I think that intentional behavior is typing without composition string because until you use Firefox's content or Blink, you won't see the underline. And this 2 kind of modes cause different behavior for us actually. See bug 1319018. Therefore, I contacted Apple, but they stopped replying me... Currently, I guess that Apple's IMEs check something special property or method of a protocol or an interface.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Not a regression of us, but might be Apple's.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 13

[Kris Maglione [:kmag]]

It's not clear whether this is still happening, or whether it's an IME bug rather than ours. It would be nice if someone could try to reproduce.

That said, my understanding is that this only shows up under specific unusual circumstances, and quickly goes away. And given that I don't see any recent reports or comments, it doesn't seem critical.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Unfortunately, this is still reproducible in macOS Ventura. I reported the odd behavior of simple IMEs on macOS to Apple, but they don't reply about it. Therefore, we can do nothing here.