Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users
Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Aug 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug
M-7

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Last Hangul letter is typed again when a composition is finished with mouse press
Reported by joone....@gmail.com, Jul 28 2010 Back to list
Chrome Version       : 6.0.477.0 (Developer Build 53759) in Ubuntu 9.10
URLs (if applicable) : http://www.google.co.kr/advanced_search?hl=en
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
           Safari 4(Mac): OK
       WebKitGtk(r64095): FAIL
Firefox4.0b1(Ubuntu9.10): FAIL
          IE 8(Windows7): OK

What steps will reproduce the problem?
1. Launch Chromium
2. Go to the above URL(google.com)
3. Turn on Korean IME
4. Set focus at "all these words:" text input field
5. Type "rksk" (가나)
6. Mouse press at the end of text or at "this exact wording or phrase:" text input field

What is the expected result?
"가나" should be typed at the current text input field with the composition end

What happens instead?
The last letter "나" is inputted again at the focused position.

Please provide any additional information below. Attach a screenshot if
possible.

 
hangul_chromium.ogv
1.1 MB Download
Comment 1 by joone....@gmail.com, Jul 28 2010
WebKitGtk has the same issue as follows,
https://bugs.webkit.org/show_bug.cgi?id=40518
Labels: -Area-Undefined Area-UI I18N
Labels: -Area-UI Area-WebKit FeedbackRequested
I was not able to reproduce this issue using Chrome 6.0.477.0 on Ubuntu 8.0.4. I was using SCIM IME to input hangul text. 

hi, joone.hur

thanks for your feedback, could you tell us what type of IME you used for inputting Hangul text? 
Comment 4 Deleted
Comment 5 by joone....@gmail.com, Jul 29 2010
I'm using IBus 1.2.0.20090927 on Ubuntu 9.10

Thanks!
Labels: -FeedbackRequested
Status: Untriaged
I don't have Ibus on linux, tested with ibus on chrome os , still don't see the issue, I'll try to see if i can find a linux box with ibus IME .
Status: Unconfirmed
Comment 8 by suzhe@chromium.org, Jul 29 2010
Status: Assigned
I can reproduce this issue on Lucid.
Comment 9 by suzhe@chromium.org, Jul 29 2010
Labels: -Area-WebKit Area-UI OS-Linux
The reasons of this issue are:

1. When the user click mouse in the text box, chrome will confirm the current composition text and ask the input method to reset its internal state by calling gtk_im_context_reset(). In case the input method may commit text unexpectedly when it's being reset, chrome set a flag before calling gtk_im_context_reset() and clear the flag after it returns, then chrome will discard all text committed by the input method when the flag is set.

2. ibus-hangul input method does commit the currently composition text when its reset method is being called. So in theory, it falls into the special flag case and the text should be discarded by chrome.

3. But unfortunately, because the input method runs in a remote process, the reset call is actually a RPC, ibus chooses to use asynchronous RPC for the call. Then from chrome's point of view, the reset call just returns immediately without any problem, but some time later a commit text arrives, then chrome thinks that it should be valid and just sends it to webkit. In this case, there is no way for chrome to know what causes the input method to commit the text.


So apparently it's a bug of ibus/ibus-hangul.


Of course we can workaround it by hooking into mouse press/release callback and discarding all commit text during a mouse click, but it won't solve the problem completely. Because:
1. The text committed by the input method may arrive any time, even after mouse press/release.
2. This issue may happen even without mouse click, for example when the input focus is reset programmatically (by JavaScript code). 



Comment 10 by js...@chromium.org, Jul 29 2010
suzhe, have you filed a bug against ibus/ibus-hangul (if it's a bug on their side as you wrote)? 
 
Comment 11 by suzhe@chromium.org, Jul 29 2010
I'll discuss with Peng Huang about the issue of ibus's async rpc call. But for ibus-hangul's behavior, whether it's a bug or not is debatable, as the semantics of gtk_im_context_reset() is unclear.
Labels: Mstone-7
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=57867 

------------------------------------------------------------------------
r57867 | suzhe@chromium.org | 2010-08-30 09:42:14 -0700 (Mon, 30 Aug 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/gtk_im_context_wrapper.cc?r1=57867&r2=57866
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/gtk_im_context_wrapper.h?r1=57867&r2=57866

[Linux]Workaround  issue 50485 

Please see  http://crbug.com/50485  for details. This CL workarounds this issue by ignoring one "commit" signal triggered when resetting the gtk imcontext.

BUG= 50485 
TEST=See bug report.

Review URL: http://codereview.chromium.org/3214001
------------------------------------------------------------------------

Comment 14 by suzhe@chromium.org, Aug 30 2010
Status: Fixed
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=67207

------------------------------------------------------------------------
r67207 | suzhe@chromium.org | Tue Nov 23 18:58:16 PST 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/gtk_im_context_wrapper.cc?r1=67207&r2=67206&pathrev=67207
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_gtk.cc?r1=67207&r2=67206&pathrev=67207

[cros] Fix two issues related to gtk im context support.

BUG=chromium-os:9208
BUG=chromium-os:9575
TEST=See bug reports.

 Issue 9208  is due to ibus's async nature: some ibus engines may update preedit string when getting reset. It may happen after calling GtkIMContextWrapper::CancelComposition() method, which then cause this method being called recursively.
So we need to suppress any preedit string signals triggered by GtkIMContextWrapper::CancelComposition() method, just like what we have done for commit signal ( http://crbug.com/50485  and issue http://crosbug.com/4792).

 Issue 9575  is caused by improper handling of "grab-notify" signal in RWHVGtk, which should not focus in the input context again when the window has been focused out.

Review URL: http://codereview.chromium.org/5372001
------------------------------------------------------------------------
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=67209

------------------------------------------------------------------------
r67209 | suzhe@chromium.org | Tue Nov 23 19:09:46 PST 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/552d/src/chrome/browser/renderer_host/gtk_im_context_wrapper.cc?r1=67209&r2=67208&pathrev=67209
 M http://src.chromium.org/viewvc/chrome/branches/552d/src/chrome/browser/renderer_host/render_widget_host_view_gtk.cc?r1=67209&r2=67208&pathrev=67209

Merge 67207 - [cros] Fix two issues related to gtk im context support.

BUG=chromium-os:9208
BUG=chromium-os:9575
TEST=See bug reports.

 Issue 9208  is due to ibus's async nature: some ibus engines may update preedit string when getting reset. It may happen after calling GtkIMContextWrapper::CancelComposition() method, which then cause this method being called recursively.
So we need to suppress any preedit string signals triggered by GtkIMContextWrapper::CancelComposition() method, just like what we have done for commit signal ( http://crbug.com/50485  and issue http://crosbug.com/4792).

 Issue 9575  is caused by improper handling of "grab-notify" signal in RWHVGtk, which should not focus in the input context again when the window has been focused out.

Review URL: http://codereview.chromium.org/5372001

TBR=suzhe@chromium.org
------------------------------------------------------------------------
Labels: -I18N bulkmove Feature-I18N
Chrome Version       : 6.0.477.0 (Developer Build 53759) in Ubuntu 9.10
URLs (if applicable) : http://www.google.co.kr/advanced_search?hl=en
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
           Safari 4(Mac): OK
       WebKitGtk(r64095): FAIL
Firefox4.0b1(Ubuntu9.10): FAIL
          IE 8(Windows7): OK

What steps will reproduce the problem?
1. Launch Chromium
2. Go to the above URL(google.com)
3. Turn on Korean IME
4. Set focus at "all these words:" text input field
5. Type "rksk" (가나)
6. Mouse press at the end of text or at "this exact wording or phrase:" text input field

What is the expected result?
"가나" should be typed at the current text input field with the composition end

What happens instead?
The last letter "나" is inputted again at the focused position.

Please provide any additional information below. Attach a screenshot if
possible.
Project Member Comment 18 by bugdroid1@chromium.org, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 19 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-UI -Mstone-7 -Feature-I18N M-7 Cr-UI Cr-UI-I18N
Project Member Comment 20 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 21 by bugdroid1@chromium.org, Mar 20 2013
Labels: -Cr-UI-I18N Cr-UI-Internationalization
Project Member Comment 22 by bugdroid1@chromium.org, Apr 23 2013
------------------------------------------------------------------------
r195916 | joone.hur@intel.com | 2013-04-23T22:19:55.676170Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/gtk_im_context_wrapper.cc?r1=195916&r2=195915&pathrev=195916
   M http://src.chromium.org/viewvc/chrome/trunk/src/AUTHORS?r1=195916&r2=195915&pathrev=195916

We don't need to set suppress_next_commit_ to false in HandleCommit() method, 
because this method can be called twice when using iBus. In this case, 
a compositing Korean Hangul character can be committed twice.  
 
Contributed by joone.hur@intel.com
 
BUG= 50485 
TEST=Follow the bug description.

Review URL: https://chromiumcodereview.appspot.com/13818036
------------------------------------------------------------------------
Sign in to add a comment