Bug 146639 - REGRESSION(r185415): [GTK] Browsers crash when an input method is enabled
Summary: REGRESSION(r185415): [GTK] Browsers crash when an input method is enabled
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk, Regression
Depends on:
Blocks:
 
Reported: 2015-07-06 08:27 PDT by Ting-Wei Lan
Modified: 2015-07-16 03:31 PDT (History)
3 users (show)

See Also:


Attachments
better backtrace (51.30 KB, text/plain)
2015-07-11 07:58 PDT, Michael Catanzaro
no flags Details
Patch (3.52 KB, patch)
2015-07-16 03:19 PDT, Carlos Garcia Campos
zan: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ting-Wei Lan 2015-07-06 08:27:01 PDT
This problem happens on both WebKitGTK+ 2.9.3 and trunk (r186298). Backtrace: http://fpaste.org/240035/14361727/

When using MiniBrowser, Epiphany, or other applications using WebKitGTK+, enabling an input method can crash the browser.
Steps to reproduce:
  1. Start the browser and click on the web page.
  2. Enable an input method and try to type something.
  3. The browser crashes.

Input methods version:
  ibus 1.5.10
  ibus-chewing 1.4.14
  ibus-anthy 1.5.6
  ibus-rawcode 1.3.2
  ibus-gucharmap 1.4.0
Comment 1 Michael Catanzaro 2015-07-11 07:58:52 PDT
Created attachment 256655 [details]
better backtrace
Comment 2 Martin Robinson 2015-07-11 08:07:22 PDT
The backtrace looks like an assertion failure. Here's the line in question:

    ASSERT(m_filterKeyEventCompletionHandler);
Comment 3 Michael Catanzaro 2015-07-12 10:07:24 PDT
Of course, m_filterKeyEventCompletionHandler is called on the next line, so there's no way a release build could survive that.

You can reproduce this crash without any input methods enabled by pressing Ctrl+Shift+u (to insert Unicode text).

I guess this has been broken since r145598.
Comment 4 Martin Robinson 2015-07-12 11:02:19 PDT
(In reply to comment #3)
> Of course, m_filterKeyEventCompletionHandler is called on the next line, so
> there's no way a release build could survive that.
> 
> You can reproduce this crash without any input methods enabled by pressing
> Ctrl+Shift+u (to insert Unicode text).
> 
> I guess this has been broken since r145598.

I suppose you mean http://trac.webkit.org/changeset/185415 here (which is bug 145598).
Comment 5 Carlos Garcia Campos 2015-07-15 05:08:10 PDT
I can't reproduce this. I assumed that the fake events were always emitted after a real event, but looking at the bt it seems I was wrong, so how can I reproduce this, when are those fake events supposed to be generated?
Comment 6 Carlos Garcia Campos 2015-07-15 05:13:10 PDT
It seems I'm using gtk-im-context-simple, not ibus, I guess that's why it doesn't crash for me.
Comment 7 Michael Catanzaro 2015-07-15 06:28:44 PDT
I can reproduce by pressing Ctrl+Shift+u in this Bugzilla form (in trunk) which causes an immediate crash. Another reproducer is to open the Region & Language panel, press the + button under Input Sources header, select Japanese (Kana Kanji) (though presumably any will work, that is the one I picked to verify with) and type anything into this Bugzilla form.

I don't know how to switch GTK+ input method handlers; ibus has been mandatory for GNOME since 3.6, and I guess your Region & Language panel will be broken without ibus.
Comment 8 Michael Catanzaro 2015-07-15 06:29:31 PDT
(In reply to comment #7)
> I can reproduce by pressing Ctrl+Shift+u in this Bugzilla form (in trunk)
> which causes an immediate crash. Another reproducer is to open the Region &
> Language panel, press the + button under Input Sources header, select
> Japanese (Kana Kanji) (though presumably any will work, that is the one I
> picked to verify with) and type anything into this Bugzilla form.

(And switch to Japanese input before typing.)
Comment 9 Carlos Garcia Campos 2015-07-15 23:14:18 PDT
(In reply to comment #7)
> I can reproduce by pressing Ctrl+Shift+u in this Bugzilla form (in trunk)
> which causes an immediate crash. Another reproducer is to open the Region &
> Language panel, press the + button under Input Sources header, select
> Japanese (Kana Kanji) (though presumably any will work, that is the one I
> picked to verify with) and type anything into this Bugzilla form.
> 
> I don't know how to switch GTK+ input method handlers; ibus has been
> mandatory for GNOME since 3.6, and I guess your Region & Language panel will
> be broken without ibus.

None of those things make ephy crash here, and region & language panel works perfectly here. I'll try to switch to ibus
Comment 10 Carlos Garcia Campos 2015-07-16 00:08:41 PDT
Ok, managed to make it crash by installing ibus-gtk3 and launching the MB with GTK_IM_MODULE=ibus. What confuses our IM filter is that ibus emits preedit-changed signal every time you type something like CTRL+Shift+u, but gtk_im_context_get_preedit_string always returns an empty string and 0 as cursor offset. Using the simple im, when you type CTRL+Shift+u + whatever, you can see the preedit string, with ibus you see nothing until the composition is confirmed. It also happens in other applications, so it's not a problem of WebKit, but ibus issue in general.
Comment 11 Carlos Garcia Campos 2015-07-16 01:50:54 PDT
(In reply to comment #10)
> Ok, managed to make it crash by installing ibus-gtk3 and launching the MB
> with GTK_IM_MODULE=ibus. What confuses our IM filter is that ibus emits
> preedit-changed signal every time you type something like CTRL+Shift+u, but
> gtk_im_context_get_preedit_string always returns an empty string and 0 as
> cursor offset. Using the simple im, when you type CTRL+Shift+u + whatever,
> you can see the preedit string, with ibus you see nothing until the
> composition is confirmed. It also happens in other applications, so it's not
> a problem of WebKit, but ibus issue in general.

This was because I had the gtk module installed but not ibus-daemon. I have the daemon running now and it crashes just by typing CTRL+Shift+u
Comment 12 Carlos Garcia Campos 2015-07-16 03:13:00 PDT
Ok, understood the whole issue now. Some input methods handle the keyboard events before the web view, so preedit signals are emitted but no key event has been handled by the web view. The solution is to send the fake events directly to the page, without going through the web view, since fake events will never generate editing commands.
Comment 13 Carlos Garcia Campos 2015-07-16 03:19:57 PDT
Created attachment 256897 [details]
Patch

This should fix the issue, it's the same behaviour as before r185415, sorry for breaking this.
Comment 14 Carlos Garcia Campos 2015-07-16 03:31:13 PDT
Committed r186892: <http://trac.webkit.org/changeset/186892>