306212 - wrong preedit string when I click the mouse buttons on textarea

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Choe Hwanjin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050822 Firefox/1.0.6 (Debian package 1.0.6-3)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050822 Firefox/1.0.6 (Debian package 1.0.6-3)

When I edit the text in textarea, I input some cjk characters by xim input
method or gtk im module. I click the left mouse button to move the carect
position when the preedit string exists. Then the caret position is moved to
where the mouse clicked, but the preedit string is not commited, so when I type
another character, the caret position is move to the old place and the preedit
string is changed. The intented behavior is that the preedit string is commited
when the user click the mouse button on textarea.

Reproducible: Always

Steps to Reproduce:
1. open some url that has text area.
2. input some text and place the caret in the middle of the text.
3. enble the input method and input some cjk characters on the caret place.
4. then click upper line or lower line to move the caret to another place.
5. input another cjk characters.

Actual Results:  
The caret moves to the old position and change the old preedit string.

Expected Results:  
When the user click the mouse, the current preedit string should be commited and
the caret should be moved to where the user clicked.

I think the solution is to call gtk_im_context_reset() on mouse click. In
GtkTextView of gtk+, it also call gtk_im_context_reset() on mouse click event.
So I made a patch for this.

Comment 1

[Choe Hwanjin]

Attachment: a patch to call gtk_im_context_reset() on mouse click event.

This patch makes firefox call gtk_im_context_reset() on mouse click event.

Comment 2

[Choe Hwanjin]

Does anyone work on this bug?

Comment 3

[Carsten Book [:Tomcat]]

Choe, can you reproduce this bug with a recent release like Firefox 2.0.0.4 ? 

Comment 4

[Choe Hwanjin]

Yes, firefox 2.0.0.4 still has this problem.

I tested on debian sid.
iceweasel    2.0.0.4  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070508 Iceweasel/2.0.0.4 (Debian-2.0.0.4-1)
libgtk2.0-0  2.10.11-2
libx11-6     1.0.3.-7

Comment 5

[Carsten Book [:Tomcat]]

choe, do you see this also with a offical (not iceweasel) Mozilla build from http://www.mozilla.com/en-US/firefox/all.html

Comment 6

[Choe Hwanjin]

Yes. Official build also has the problem.

I think you did something different from me, so you cannot reproduce this bug.
Follow this step.

1. Install korean input method.
2. Input "abcd efgh".
3. Press "shift + space" to change korean input mode.
4. Press "rkskek", and do not press any key or move mouse.
  On this moment, you can see some reversed korean chars.
5. Move the mouse pointer between 'b' and 'c'. Be careful not to leave the firefox window while you move the mouse pointer.
6. Click between b and c.
7. Press "fkakqk". Then the new inputed chars appended at the old place where the preedit string is.

Currect behavior is to commit current preedit string when the user click the mouse and move the caret to the clicked point. But current firefox doesn't behave like that.

Comment 7

[Samuel Sidler (old account; do not CC)]

Choe, one more question. Does this happen with a trunk build?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 8

[Choe Hwanjin]

I've tested firefox-3.0a6pre.en-US.linux-i686.tar.bz2.
And it works fine.

Thanks a lot!

Comment 9

[Samuel Sidler (old account; do not CC)]

Resolving this bug as WORKSFORME since it's fixed on the trunk and we're not sure what check in fixed it. This fix for this bug will be seen in Firefox 3.