269.30 KB, application/pdf
5.30 KB, image/png
After update of Tb 31, Korean address suggestion is not working. I'll attach screen captures soon.
Created attachment 8479624 [details] Screen-shots for bug of Korean autocomplete in addressbook Screen-shots for bug of Korean autocomplete in addressbook
Aceman, how did this technically get assigned to you on bugzilla, I don't see any comment or history entry where the assignment was made? Is that a new bug on bugzilla? Can you look into this bug about Korean autocomplete? Channy, thanks for the bug report. Are you suggesting that autocomplete doesn't work for ANY Korean contacts, or it works for some and fails for some?
I guess this bug is related to Bug 354358.
(In reply to Thomas D. from comment #2) > Aceman, how did this technically get assigned to you on bugzilla, I don't > see any comment or history entry where the assignment was made? Is that a > new bug on bugzilla? Reporters can assign a bug to anyone... Channy: can you provide a sample korean name that doesn't work?
(In reply to Thomas D. from comment #2) > Channy, thanks for the bug report. > Are you suggesting that autocomplete doesn't work for ANY Korean contacts, > or it works for some and fails for some? Yes. ANY Korean contacts are affected. (In reply to Thomas D. from comment #4) > Channy (reporter), could you pls answer my comment 2 and explain your > comment 3? According to Bug Bug 354358, Korean character was made by combination of Korean alphabets, but complete Korean character can not be recognized by keyup event issue on Firefox. Thunderbird's new code will be followed by this event handling. We have to survey codes for Korean characters before refactoring. Please test with as following names: 김가나 김길동 홍길동 홍가나
(In reply to Channy Yun [:channy] from comment #6) > (In reply to Thomas D. from comment #4) > > Channy (reporter), could you pls answer my comment 2 and explain your > > comment 3? > > According to Bug Bug 354358, Korean character was made by combination of > Korean alphabets, but complete Korean character can not be recognized by > keyup event issue on Firefox. Thunderbird's new code will be followed by > this event handling. So is this a bug in the core event handling? > We have to survey codes for Korean characters before > refactoring. What do you mean here? > Please test with as following names: > 김가나 > 김길동 > 홍길동 > 홍가나 Can this be tested on a US keyboard? Does the problem show if I copy and paste some of these characters from this comment into the addressing widget?
Created attachment 8697773 [details] Showing Korean suggestions after pressing right-arrow I know a few words of Korean, I know how the Korean alphabet works and how Korean characters are entered using IME. I observed the following: When you copy - say - 김 into the address field the auto-completion works. If you type the character with single letters, ㄱ ㅣ ㅁ, the auto-completion doesn't work. However, when you press right-arrow (or space) after completing one character, you will invoke the auto-completion, see attached. Over all, I don't think it's such a terrible problem, and since the widgets are handled by Mozilla central code, the Thunderbird people can't do anything about it. But I can refer the matter to someone who knows.
Channy, is this reported for Windows only? Masayuki-san, can you please take a look and comment. Is there something missing for Korean?
Oh, now it's downing on me. You *cannot* tell when the character is finished. The character could be 나 or 남, so after typing ㄴ and ㅏ, how will the system know that the character is done? If you press right-arrow, the character entry is obviously done and the auto-complete starts. This is not a regression, it works the same in TB 31.6, TB 38.4 and the developer version TB 45. Or where do you see the difference?
Yep, Korean IME behaves odd to me. That the reason our XP code which handle compositionend won't work with Korean IME on Windows. IIRC, I have a patch for this in my home's PC. I'll check it.
Any update on this after more than three months?
Sorry for the delay to reply. I thought that this is fixed by other bugs (I forgot the bug#). But different from my guess, looks like this is not a regression of TSF. Even in IMM, at a typing a couple of Syllables, the characters are combined in composition string and typing a Syllable for starting to input next Hangul, first composition is committed but starts next composition. So, composition is never finished during you're typing Hangul characters continuously. So, I don't know if the Thunderbird's address autocomplete is using autocomplete module in toolkit, there is no chance to work autocomplete. If Thunderbird tries to insert the first suggested text after composition string, the composition is committed forcibly since our editor cannot allow to modify editor's content during composition. So, I think that Thunderbird's autocomplete needs to be redesigned for Korean language aware (e.g., just dropping down the suggest list while there is composition). So, I think that this must not be related to bug 354358. Note that pressing ArrowRight key causes committing composition and forcibly makes autocomplete work.
TB is using toolkit/components/autocomplete since TB 31. Before it used XPFE. As I stated in comment #10, and as you are confirming now, "composition" is never finished while you're typing Hangul characters continuously. In that comment I suggested to use the right arrow key to tell the system that you're finished entering. I think this is quite an acceptable approach. We have no experts on this in the TB team to redesign autocomplete for Korean.
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #15) > Perhaps, bug 1282628 is a reproducible case on Firefox. which was fixed by bug 1224994. is this bug still occurring in latest builds?
I can see no difference when entering recipients into a TB composition window. I did the same as in comment #8 in Dec. 2015, this time with a Daily TB 51a1. When I type ㄱ ㅣ ㅁ (which is rla) I get 김, the autocompletion only works if I press right-arrow or click behind the character. I think it works as well as one can expect, see comment #10. Should we close this bug here? Bug 1282628 was a different complaint.