Bug 146639 – REGRESSION(r185415): [GTK] Browsers crash when an input method is enabled

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Ting-Wei Lan]

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

[Michael Catanzaro]

Created attachment 256655 [details]
better backtrace

[Martin Robinson]

The backtrace looks like an assertion failure. Here's the line in question:

    ASSERT(m_filterKeyEventCompletionHandler);

[Michael Catanzaro]

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.

[Martin Robinson]

(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).

[Carlos Garcia Campos]

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?

[Carlos Garcia Campos]

It seems I'm using gtk-im-context-simple, not ibus, I guess that's why it doesn't crash for me.

[Michael Catanzaro]

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.

[Michael Catanzaro]

(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.)

[Carlos Garcia Campos]

(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

[Carlos Garcia Campos]

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.

[Carlos Garcia Campos]

(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

[Carlos Garcia Campos]

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.

[Carlos Garcia Campos]

Created attachment 256897 [details]
Patch

This should fix the issue, it's the same behaviour as before r185415, sorry for breaking this.

[Carlos Garcia Campos]

Committed r186892: <http://trac.webkit.org/changeset/186892>