Closed Bug 226784 Opened 18 years ago Closed 13 years ago

Caret display problems with Korean input methods in Windows

Categories

(Core :: Widget: Win32, defect)

x86
Windows 2000
defect
Not set
minor

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: soobongp, Assigned: masayuki)

References

(Depends on 1 open bug)

Details

(Keywords: verified1.9.1)

Attachments

(1 file, 4 obsolete files)

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.
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
Attached patch Patch v1.0 (obsolete) — Splinter Review
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?
Attached patch Patch v2.0 (obsolete) — Splinter Review
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.
Attachment #352108 - Attachment is obsolete: true
Attachment #352401 - Flags: review?(VYV03354)
Attachment #352108 - Flags: review?(VYV03354)
Attached patch Patch v2.1 (obsolete) — Splinter Review
oops, we should check the return value of ::ImmGetCompositionString.
Attachment #352401 - Attachment is obsolete: true
Attachment #352403 - Flags: review?(VYV03354)
Attachment #352401 - Flags: review?(VYV03354)
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)
Attachment #352403 - Flags: review?(emaijala) → review+
Comment on attachment 352403 [details] [diff] [review]
Patch v2.1

+#define NS_TEXTRANGE_RAWINPUT              0X02

Change the X to lowercase while at it.
Attachment #352403 - Flags: superreview?(roc)
Attached patch Patch v2.1.1 (obsolete) — Splinter Review
fix comment 13, sorry for the spam.
Attachment #352403 - Attachment is obsolete: true
Attachment #352974 - Flags: superreview?(roc)
Attachment #352403 - Flags: superreview?(roc)
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.
Attached patch Patch v2.1.2Splinter Review
Attachment #352974 - Attachment is obsolete: true
Attachment #353051 - Flags: superreview+
Attachment #353051 - Flags: review+
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
Keywords: fixed1.9.1
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
You need to log in before you can comment on or make changes to this bug.