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
Created attachment 256655 [details] better backtrace
The backtrace looks like an assertion failure. Here's the line in question: ASSERT(m_filterKeyEventCompletionHandler);
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.
(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).
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?
It seems I'm using gtk-im-context-simple, not ibus, I guess that's why it doesn't crash for me.
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.
(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.)
(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
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.
(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
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.
Created attachment 256897 [details] Patch This should fix the issue, it's the same behaviour as before r185415, sorry for breaking this.
Committed r186892: <http://trac.webkit.org/changeset/186892>