Bug 30389 - [gtk] Input method does not work in Epiphany
Summary: [gtk] Input method does not work in Epiphany
Status: RESOLVED DUPLICATE of bug 32290
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-15 09:06 PDT by Duy Nguyen
Modified: 2010-02-11 14:03 PST (History)
7 users (show)

See Also:


Attachments
gtkim.patch (3.76 KB, patch)
2009-12-29 20:08 PST, Duy Nguyen
no flags Details | Formatted Diff | Diff
gtkim.patch (3.80 KB, patch)
2009-12-29 20:13 PST, Duy Nguyen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Duy Nguyen 2009-10-15 09:06:57 PDT
The original report is here: https://bugzilla.gnome.org/show_bug.cgi?id=598563

Epiphany used to recognize GTK_IM_MODULE and set input method
for every textbox correctly, changing input method from urlbar also affected
all textboxes. With recent Webkit, it seems input method is set to default
input method, no way I can change it to XIM or Vietnames VIQR.

Xan suspected the culprit was r48964.
Comment 1 Martin Robinson 2009-10-15 11:25:12 PDT
I can't seem to reproduce this behavior using GtkLauncher. Setting GTK_IM_MODULE seems to change the IM context properly. Also, I can't find an example of a GTK+ app which shares the selected IM context between text fields (libgtk-x11-2.0.so.0.1600.1). Duy, any tips on reproducing this?
Comment 2 Duy Nguyen 2009-10-15 18:25:59 PDT
Funny GTK_IM_MODULE works with GtkLauncher for me too. But you can also start GtkLauncher without GTK_IM_MODULE and set IM in url bar. New IM does not affect textboxes. At least Epiphany used to support this way.

The way I tested it is starting epiphany www.google.com with GTK_IM_MODULE, then type something. I also confirm that epiphany broke with 48964 and worked with 48963.

I'm using Gtk+ 2.18.2, Glib 2.22.2, libsoup near to master, LANG=vi_VN.UTF-8.
Comment 3 Duy Nguyen 2009-12-24 05:17:04 PST
Another observation. Gedit (and GtkEntry) seems to react well with XSettings "gtk-im-module" changes. I change /desktop/gnome/interface/gtk-im-module (then gnome-settings-daemon will update xsettings accordingly) and Gedit/GtkEntry react well with the new input method. Webview does not though. After a view is created, it sticks with the selected input method at that moment forever.
Comment 4 Duy Nguyen 2009-12-24 05:21:47 PST
Ohh.. and GtkLauncher will pick up the new input method if you use context menu to change IM to something else, then back to system input method. Looks like some hook is missing.
Comment 5 Duy Nguyen 2009-12-25 01:13:57 PST
To sum it up:
 - Looking at the source, I don't know how the old Epiphany could share input method too, but that would not matter if we had a way to change input method.
 - Speaking of changing system input method via XSettings, WebKit does not call gtk_im_context_focus_{in,out} frequent enough (which explains my last comment). The only place it calls those is in EditorClient::setInputMethodState(), which does not get called if I switch windows, though switching text entry does the trick. Focus problem.
 - A more important bug with input methods. It seems composition in webkit is not right. With input method VIQR, I can type "am" in a GtkEntry and get "am" ('a' will put it to preedit mode, 'a^m' for example will produce 'âm'). With WebKit "am" produces "m". The preedit 'a' is eaten. The only way I can have 'am' is typing 'a\m' -- 'a\' will produce a complete 'a'.
Comment 6 Duy Nguyen 2009-12-29 20:08:37 PST
Created attachment 45632 [details]
gtkim.patch

This addresses my last point in the last comment. It seems GtkIMContext can emit multiple commit and preedit-changed signals in one row.

I tested it with VIQR input method. You can try to type these in GtkLauncher and a normal GtkEntry to see if the behaviour matches:

aan
bba<move left>d (this does not work correctly due to cursor position, but at least it does not emit "badba")

My first attempt to make a proper patch, take it easy :)
Comment 7 WebKit Review Bot 2009-12-29 20:11:57 PST
Attachment 45632 [details] did not pass style-queue:

Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
WebKit/gtk/WebCoreSupport/EditorClientGtk.cpp:78:  Tab found; better to use spaces  [whitespace/tab] [1]
WebKit/gtk/WebCoreSupport/EditorClientGtk.cpp:78:  Use 0 instead of NULL.  [readability/null] [5]
WebKit/gtk/WebCoreSupport/EditorClientGtk.cpp:80:  Tab found; better to use spaces  [whitespace/tab] [1]
WebKit/gtk/WebCoreSupport/EditorClientGtk.cpp:507:  Tab found; better to use spaces  [whitespace/tab] [1]
WebKit/gtk/ChangeLog:6:  Line contains tab character.  [whitespace/tab] [5]
Total errors found: 5
Comment 8 Duy Nguyen 2009-12-29 20:13:57 PST
Created attachment 45633 [details]
gtkim.patch

Tab-damaged
Comment 9 WebKit Review Bot 2009-12-29 20:17:27 PST
Attachment 45633 [details] did not pass style-queue:

Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
WebKit/gtk/WebCoreSupport/EditorClientGtk.cpp:78:  Use 0 instead of NULL.  [readability/null] [5]
Total errors found: 1
Comment 10 Eric Seidel (no email) 2010-01-05 14:19:29 PST
Comment on attachment 45633 [details]
gtkim.patch

How do we test this?  Does this already have a manual test?  Can we make a layout test?
Comment 11 Duy Nguyen 2010-01-07 05:00:35 PST
(In reply to comment #10)
> (From update of attachment 45633 [details])
> How do we test this?  Does this already have a manual test?  Can we make a
> layout test?

A simple manual test was given in comment #6 (reference behavior is from GtkEntry). I don't know what a layout test is. But I think I can simulate signals sent from an input method (in this case, VIQR) and check the result.
Comment 12 Duy Nguyen 2010-01-07 07:42:24 PST
I think I can extend testkeyevents.c to cover this bug, but how can I get text from a text field? Document::getElementById() is C++ and thus not accessible from testkeyevents.c.
Comment 13 Gustavo Noronha (kov) 2010-01-07 16:45:55 PST
(In reply to comment #12)
> I think I can extend testkeyevents.c to cover this bug, but how can I get text
> from a text field? Document::getElementById() is C++ and thus not accessible
> from testkeyevents.c.

This should be easily doable with JavaScriptCore. Look at how Epiphany implements saving form passwords currently (commits should be easy to find, because they are close to HEAD).
Comment 14 Martin Robinson 2010-01-30 19:45:33 PST
Hey Dan (and others having trouble). I've taken your patch here and incorporated it into my work at 32290. It feels like these fixes belong together. I'd love it if you could confirm this fixes your issues (except the focus_(in/out) issue which I think deserves another patch -- forthcoming!). Do you mind checking out my latest patch on that bug and letting me know if this improve the behavior?

I can handle writing the tests for these issues. The tests for the two behaviors will be very similar.
Comment 15 Duy Nguyen 2010-02-04 07:05:20 PST
Looks like the patch on bug 32290 solves this issue well.

*** This bug has been marked as a duplicate of bug 32290 ***
Comment 16 Oliver Hunt 2010-02-11 14:03:57 PST
Comment on attachment 45633 [details]
gtkim.patch

clearing review flag based on prior comments