Closed Bug 226784 Opened 18 years ago Closed 13 years ago
Caret display problems with Korean input methods in Windows
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Problem : Caret is displayed to the left side of Korean characters during pre-edit. This is bothering Korean users because the caret is usually either not visible in pre-edit or placed to the right side of the pre-edit area. Cause of the problem : Windows IME. Windows Korean IME returns the caret position to the left side of the korean but it has been OK since the pre-edit area is always inverted, so it actually hides the caret or some applications disables the caret while composition is going on. Suggestion : We can not change the behavior of Korean IME in Windows, so hiding the caret while composition is going on, and display it after committed. Reproducible: Always Steps to Reproduce: 1. Install Firebird 0.7 to windows 2000 2. Type in some korean character into a textfield 3. Observe the cursor displaying to the left of the pre-edit Expected Results: Suggestion : We can not change the behavior of Korean IME in Windows, so hiding the caret while composition is going on, and displaying it after committed.
Confirming with Gecko/20040119 on Korean WinXP using MS IME 2003. Severity to minor, because there is no loss of function from this bug.
Severity: major → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is this still an issue with current trunk build? ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk
Yes, the issue is still alive on firefox 3.0.4. Nobody working on it? It has no loss of function but quite uncompotable to input Korean characters. On Linux, this issue does not happen.
Yes, the issue is still alive on firefox 3.0.4. Nobody working on it? It has no loss of function but quite uncomfotable to input Korean characters. On Linux, this issue does not happen.
Could you perhaps test with a trunk build? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
Trunk build still keeps the issue.
The Korean IME which is default IME on Vista returns 0 for cursor position via ImmGetCompositionStringW. And also clause length is also 0. The IME's behavior is bad :-(
Assignee: smontagu → nobody
Component: Internationalization → Widget: Win32
QA Contact: amyy → win32
Korean IME doesn't return clause information correctly. Then, we are processing the composition string specially. Then, the cursor pos should be end of the composition string, probably.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attachment #352108 - Flags: review?(VYV03354)
If this is risky, we can add the limitation for the new code: * the current keyboard layout is 949. * the current composition string length is 1. * the current cursor position is 0. Do we have other conditions?
Thank you, Kimura-san for your review in bugzilla-jp. I think that we need to change IME caret undefined case at (sIMECompClauseLength > 0) case too. And also I add notice comments to nsGUIEvent.h and nsIPrivateTextRange.h.
oops, we should check the return value of ::ImmGetCompositionString.
Comment on attachment 352403 [details] [diff] [review] Patch v2.1 > I think that we need to change IME caret undefined case at > (sIMECompClauseLength > 0) case too. Good catch.
Attachment #352403 - Flags: review?(VYV03354) → review+
Attachment #352403 - Flags: review?(emaijala)
Comment on attachment 352403 [details] [diff] [review] Patch v2.1 +#define NS_TEXTRANGE_RAWINPUT 0X02 Change the X to lowercase while at it.
fix comment 13, sorry for the spam.
Attachment #352974 - Flags: superreview?(roc) → superreview+
Comment on attachment 352974 [details] [diff] [review] Patch v2.1.1 + // Note that the range array may not have an express caret position. + // So, an array may not have TEXTRANGE_CARETPOSITION typed range. // Note that the range array may not specify a caret position; in that // case there will be no range of type TEXTRANGE_CARETPOSITION in the array.
checked-in to trunk http://hg.mozilla.org/mozilla-central/rev/79136a417a3a
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [c-n: baking for 1.9.1]
Target Milestone: --- → mozilla1.9.2a1
Isaac, could you perhaps test in current trunk builds, to see if this is now fixed for you? ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk Masayuki, thanks for fixing this!
It is fixed. Much better to use. Thanks Masayuki.
Thank you for your verification.
Comment on attachment 353051 [details] [diff] [review] Patch v2.1.2 This patch only changes the behavior of some IMEs which doesn't support caret position property. Most IMEs support it. I don't know such IMEs other than the standard Korean IME.
Attachment #353051 - Flags: approval1.9.1?
Comment on attachment 353051 [details] [diff] [review] Patch v2.1.2 a191=beltzner
Attachment #353051 - Flags: approval1.9.1? → approval1.9.1+
pushed to 1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5dec81af74a7
Whiteboard: [c-n: baking for 1.9.1]
Per comment #19, marking verified for trunk. Can someone with korean IME verify this on the 1.9.1 branch? Builds here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1-l10n/
Status: RESOLVED → VERIFIED
(In reply to comment #24) > ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1-l10n/ verified 1.9.1
You need to log in before you can comment on or make changes to this bug.