This bug was filed from the Socorro interface and is report bp-415dbd3f-d204-4f2d-a57a-6baf00170804. ============================================================= STR: 1. Open several tabs(ex: 7 tabs) connecting to different sites(yahoo, facebook, etc.) 2. In one of the tabs, switch to Chinese IME and type some characters but don't commit 3. Switch back to English mode 4. Hold down Ctrl-PgDn to switch between tabs quickly 5. In 3 seconds the tab switching will stuck in one tab 6. Click mouse cursor at a different tab -> crash happened

As it's easy to reproduce, I can use mozregression to find when the problem started to happen. 1. The tab stuck(step 5) started to happen after bug 1362866. 2. The crash(step 6) started to happen after bug 1377672.

Thank you for finding the regression point. That means that we still have some bugs handling delayed message between processes. Could you tell me your environment? Distribution, IM and convert engine?

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #2) > Thank you for finding the regression point. That means that we still have > some bugs handling delayed message between processes. > > Could you tell me your environment? Distribution, IM and convert engine? Here's my environment. OS: Ubuntu 16.04 IME: https://wiki.ubuntu-tw.org/index.php?title=Gcin What do you mean by convert engine?

(In reply to Shian-Yow Wu [:swu] (56 Regression Engineering support) from comment #3) > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #2) > > Thank you for finding the regression point. That means that we still have > > some bugs handling delayed message between processes. > > > > Could you tell me your environment? Distribution, IM and convert engine? > > Here's my environment. > > OS: Ubuntu 16.04 > IME: https://wiki.ubuntu-tw.org/index.php?title=Gcin > > What do you mean by convert engine? Looks like Gcin is the convert engine. IM is, e.g., iBus, Fcitx, etc.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #4) > (In reply to Shian-Yow Wu [:swu] (56 Regression Engineering support) from > comment #3) > > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #2) > > > Thank you for finding the regression point. That means that we still have > > > some bugs handling delayed message between processes. > > > > > > Could you tell me your environment? Distribution, IM and convert engine? > > > > Here's my environment. > > > > OS: Ubuntu 16.04 > > IME: https://wiki.ubuntu-tw.org/index.php?title=Gcin > > > > What do you mean by convert engine? > > Looks like Gcin is the convert engine. IM is, e.g., iBus, Fcitx, etc. The gcin, when installed, can be chosen between ibus/fcitx/gcin in "System Settings"->"Language Support". So it seems to be IM in your definition. Here is another link[1] about installing gcin in Ubuntu 16.04(but all in Chinese). [1] http://dchesmis.blogspot.tw/2016/09/ubuntu-1604gcin.html

Forgot to mention that I tested using 注音(Zhuyin) of gcin.

Oh, looks like that gcin is a new IM. SO, yes, Zhuyin is what I was asking as convert engine. How did you install it to Ubuntu? I see only anthy as its convert engine in apt list of Ubuntu 17.04.

And I wonder, can the patch for bug 1388647 fix this bug too? Patch: https://bugzilla.mozilla.org/attachment.cgi?id=8895747 Test builds: Linux-x86: https://queue.taskcluster.net/v1/task/PfTZQKWzSHC4OnNniro4fw/runs/0/artifacts/public/build/target.tar.bz2 Linux-x64: https://queue.taskcluster.net/v1/task/RJe_TTXNQHqc8yfa3nI6hw/runs/0/artifacts/public/build/target.tar.bz2

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #7) > Oh, looks like that gcin is a new IM. SO, yes, Zhuyin is what I was asking > as convert engine. > > How did you install it to Ubuntu? I see only anthy as its convert engine in > apt list of Ubuntu 17.04. The link in comment 5 only provided gcin versions up to Ubuntu 16.04. If the Zhuyin convert engine is not available for 17.04, maybe it will be easier to test it on 16.04 or older Ubuntu versions.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #8) > And I wonder, can the patch for bug 1388647 fix this bug too? > Patch: > https://bugzilla.mozilla.org/attachment.cgi?id=8895747 > Test builds: > Linux-x86: > https://queue.taskcluster.net/v1/task/PfTZQKWzSHC4OnNniro4fw/runs/0/ > artifacts/public/build/target.tar.bz2 > Linux-x64: > https://queue.taskcluster.net/v1/task/RJe_TTXNQHqc8yfa3nI6hw/runs/0/ > artifacts/public/build/target.tar.bz2 I tested the Linux-x64 version, it still stucks in step 6, but will not crash when click other tabs in step 7(which is better). However, after tab stuck happens in step 6, it will crash if I switch to the other window by pressing Alt-Tab.

Yeah, on 17.04, gcin is crashed when I switch it to Zhuyin mode. Additionally, when I switch to other modes like 倉頡 and typing ShiftLeft key to switch to English mode, the composition disappears and I don't see any problem...

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #11) > Yeah, on 17.04, gcin is crashed when I switch it to Zhuyin mode. > Additionally, when I switch to other modes like 倉頡 and typing ShiftLeft key > to switch to English mode, the composition disappears and I don't see any > problem... Just to make sure, do you mean gcin itself crashed on your 17.04? Or you can reproduce the Firefox crash by using Zhuyin mode of gcin?

(In reply to Shian-Yow Wu [:swu] (56 Regression Engineering support) from comment #12) > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #11) > > Yeah, on 17.04, gcin is crashed when I switch it to Zhuyin mode. > > Additionally, when I switch to other modes like 倉頡 and typing ShiftLeft key > > to switch to English mode, the composition disappears and I don't see any > > problem... > > Just to make sure, do you mean gcin itself crashed on your 17.04? Or you > can reproduce the Firefox crash by using Zhuyin mode of gcin? Ah, I meant gcin crashed only when I switch the convert engine to 注音. Client applications like Firefox are fine.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #13) > (In reply to Shian-Yow Wu [:swu] (56 Regression Engineering support) from > comment #12) > > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #11) > > > Yeah, on 17.04, gcin is crashed when I switch it to Zhuyin mode. > > > Additionally, when I switch to other modes like 倉頡 and typing ShiftLeft key > > > to switch to English mode, the composition disappears and I don't see any > > > problem... > > > > Just to make sure, do you mean gcin itself crashed on your 17.04? Or you > > can reproduce the Firefox crash by using Zhuyin mode of gcin? > > Ah, I meant gcin crashed only when I switch the convert engine to 注音. Client > applications like Firefox are fine. Then it seems you may need to try it on 16.04 or older versions...

This info might be helpful before you can reproduce it locally. Here is the GDB backtrace using the step in comment 10, based on m-c after bug 1388647 landed. Thread 1 "firefox" received signal SIGSEGV, Segmentation fault. nsIWidget::IMENotificationRequestsRef (this=0x0) at /home/sywu/work/src/mozilla-central/widget/nsBaseWidget.cpp:2360 2360 TextEventDispatcher* dispatcher = GetTextEventDispatcher(); (gdb) bt #0 nsIWidget::IMENotificationRequestsRef (this=0x0) at /home/sywu/work/src/mozilla-central/widget/nsBaseWidget.cpp:2360 #1 0x00007fffe86856ac in mozilla::IMEStateManager::OnChangeFocusInternal (aPresContext=<optimized out>, aPresContext@entry=0x0, aContent=<optimized out>, aContent@entry=0x0, aAction=..., aAction@entry=...) at /home/sywu/work/src/mozilla-central/dom/events/IMEStateManager.cpp:490 #2 0x00007fffe8685786 in mozilla::IMEStateManager::OnChangeFocus (aPresContext=0x0, aContent=aContent@entry=0x0, aCause=aCause@entry=mozilla::widget::InputContextAction::CAUSE_UNKNOWN) at /home/sywu/work/src/mozilla-central/dom/events/IMEStateManager.cpp:438 #3 0x00007fffe7d14f25 in nsFocusManager::Blur (this=this@entry=0x7fffe43d50b0, aWindowToClear=aWindowToClear@entry=0x0, aAncestorWindowToFocus=aAncestorWindowToFocus@entry=0x0, aIsLeavingDocument=aIsLeavingDocument@entry=true, aAdjustWidgets=aAdjustWidgets@entry=true, aContentToFocus=aContentToFocus@entry=0x0) at /home/sywu/work/src/mozilla-central/dom/base/nsFocusManager.cpp:1674 #4 0x00007fffe7d15b58 in nsFocusManager::WindowLowered (this=0x7fffe43d50b0, aWindow=0x7fffd24d9020) at /home/sywu/work/src/mozilla-central/dom/base/nsFocusManager.cpp:810 #5 0x00007fffea13f6ef in nsWebShellWindow::WindowDeactivated (this=0x7fffd7b04660) at /home/sywu/work/src/mozilla-central/xpfe/appshell/nsWebShellWindow.cpp:500 #6 0x00007fffe8f017ab in nsWindow::DispatchDeactivateEvent (this=this@entry=0x7fffd24e2000) at /home/sywu/work/src/mozilla-central/widget/gtk/nsWindow.cpp:533 #7 0x00007fffe8f0803d in nsWindow::OnContainerFocusOutEvent (this=this@entry=0x7fffd24e2000, aEvent=aEvent@entry=0x7fffb5b4f790) at /home/sywu/work/src/mozilla-central/widget/gtk/nsWindow.cpp:2908 #8 0x00007fffe8f086ea in focus_out_event_cb (widget=<optimized out>, event=0x7fffb5b4f790) at /home/sywu/work/src/mozilla-central/widget/gtk/nsWindow.cpp:5677 #9 0x00007ffff600afac in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #10 0x00007ffff34c3fa5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x00007ffff34d5fc1 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x00007ffff34de7f9 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x00007ffff34df08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x00007ffff6148c3c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #15 0x00007ffff615903e in gtk_widget_send_focus_change () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #16 0x00007ffff615d450 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #17 0x00007ffff616c40d in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0x00007ffff616c5eb in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #19 0x00007ffff600afac in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #20 0x00007ffff34c3fa5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x00007ffff34d656e in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #22 0x00007ffff34de7f9 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #23 0x00007ffff34df08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #24 0x00007ffff6148c3c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #25 0x00007ffff600a176 in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #26 0x00007ffff5b77d92 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #27 0x00007ffff31ed197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #28 0x00007ffff31ed3f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #29 0x00007ffff31ed49c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #30 0x00007fffe8f216cf in nsAppShell::ProcessNextNativeEvent (this=<optimized out>, mayWait=<optimized out>) at /home/sywu/work/src/mozilla-central/widget/gtk/nsAppShell.cpp:280 #31 0x00007fffe8ee8f5c in nsBaseAppShell::DoProcessNextNativeEvent (this=this@entry=0x7fffdbaac340, mayWait=<optimized out>) at /home/sywu/work/src/mozilla-central/widget/nsBaseAppShell.cpp:140 #32 0x00007fffe8ee9130 in nsBaseAppShell::OnProcessNextEvent (this=0x7fffdbaac340, thr=0x7ffff6bb6d50, mayWait=true) at /home/sywu/work/src/mozilla-central/widget/nsBaseAppShell.cpp:291 #33 0x00007fffe6b57593 in nsThread::ProcessNextEvent (this=0x7ffff6bb6d50, aMayWait=<optimized out>, aResult=0x7fffffffc357) at /home/sywu/work/src/mozilla-central/xpcom/threads/nsThread.cpp:1482 #34 0x00007fffe6b5129c in NS_ProcessNextEvent (aThread=<optimized out>, aThread@entry=0x7ffff6bb6d50, aMayWait=aMayWait@entry=true) at /home/sywu/work/src/mozilla-central/xpcom/threads/nsThreadUtils.cpp:521 #35 0x00007fffe70845c9 in mozilla::ipc::MessagePump::Run (this=0x7fffe439e780, aDelegate=0x7fffe439f380) at /home/sywu/work/src/mozilla-central/ipc/glue/MessagePump.cpp:125 #36 0x00007fffe7028261 in MessageLoop::RunInternal (this=<optimized out>) at /home/sywu/work/src/mozilla-central/ipc/chromium/src/base/message_loop.cc:326 #37 MessageLoop::RunHandler (this=<optimized out>) at /home/sywu/work/src/mozilla-central/ipc/chromium/src/base/message_loop.cc:319 #38 MessageLoop::Run (this=<optimized out>) at /home/sywu/work/src/mozilla-central/ipc/chromium/src/base/message_loop.cc:299 #39 0x00007fffe8edfa39 in nsBaseAppShell::Run (this=0x7fffdbaac340) at /home/sywu/work/src/mozilla-central/widget/nsBaseAppShell.cpp:158 #40 0x00007fffea4002a6 in nsAppStartup::Run (this=0x7fffdbaf27e0) at /home/sywu/work/src/mozilla-central/toolkit/components/startup/nsAppStartup.cpp:287 #41 0x00007fffea4a6673 in XREMain::XRE_mainRun (this=this@entry=0x7fffffffc690) at /home/sywu/work/src/mozilla-central/toolkit/xre/nsAppRunner.cpp:4646 #42 0x00007fffea4a77a1 in XREMain::XRE_main (this=this@entry=0x7fffffffc690, argc=argc@entry=4, argv=argv@entry=0x7fffffffd9e8, aConfig=...) at /home/sywu/work/src/mozilla-central/toolkit/xre/nsAppRunner.cpp:4810 #43 0x00007fffea4a7c1d in XRE_main (argc=4, argv=0x7fffffffd9e8, aConfig=...) at /home/sywu/work/src/mozilla-central/toolkit/xre/nsAppRunner.cpp:4905 #44 0x0000000000406080 in do_main (argc=argc@entry=4, argv=argv@entry=0x7fffffffd9e8, envp=envp@entry=0x7fffffffda10) at /home/sywu/work/src/mozilla-central/browser/app/nsBrowserApp.cpp:236 #45 0x0000000000405974 in main (argc=4, argv=0x7fffffffd9e8, envp=0x7fffffffda10) at /home/sywu/work/src/mozilla-central/browser/app/nsBrowserApp.cpp:309

Is it planned to fix this issue in Firefox 56?

Currently, no. I don't think that switching tab while there is a composition isn't so major scenario. However, I've not seen the actual behavior of Zhuyin of gcin. So, if it'd be a major scenario of its usage, we might have needed to fix soon, though. However, anyway, it won't work with the latest Ubuntu. So, I bet that gcin isn't used by so many our users.

I imagine that most of our users are on Ubuntu 14.04/16.04 LTS(Long Term Support) instead of 17.04/17.10, though the total number of gcin users on Ubuntu is not major[1]. Firefox is currently the default browser on Ubuntu, and we hope Firefox keeps to be the default browser of 18.04 LTS[2]. Taking this into consideration, if the issue is not fixed in 56, it seems to me that we should at least fix it in 57. [1] http://popcon.ubuntu.com/by_inst [2] https://docs.google.com/forms/d/e/1FAIpQLScOZggYro5S5okO8yhoGI5h2ucicBZPGGLYGOI6dINA1WSTzQ/viewform

Tracking for 57 since we should probably fix this for Ubuntu users on more recent versions.

Hmm, I installed Ubuntu 16.04 LTS and gcin. However, pressing Ctrl+Alt+3 causes gcin crashing. It's really unstable. Is it really used by typical Traditional Chinese users of Ubuntu? The error message is: "Cannot open /usr/share/gcin/table/.kbm".

I give up to reproduce this bug in my environments. swu: Could you attach a log file at crash with following STR? 1. Open 3 tabs (if not enough, open more tabs) they all are about:home 2. Open about:networking 3. Choose "Logging" of the left pain 4. Replace the input field of "Current Log File:" with a log file path where you want to save them (you need to specify this with full path, so, ~/foo.log isn't available), then, click "Set Log File". 5. Replace the input field of "Current Log Modules:" with "nsGtkIMModuleWidgets:5,KeymapWrapperWidgets:5,IMEStateManager:5,sync", then, click "Set Log Modules" 6. Click "Start Logging" and close the tab. 7. Back to one of "about:home" tab. 8. Type a character in the input field of "about:home" but don't commit it. 9. Press Ctrl+PgDn to switch tabs until crashing. Then, attach the file "foo-main.<process number>" to this bug. Please note that don't type any private information like passwords since all key events are logged.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #20) > Hmm, I installed Ubuntu 16.04 LTS and gcin. However, pressing Ctrl+Alt+3 > causes gcin crashing. It's really unstable. Is it really used by typical > Traditional Chinese users of Ubuntu? The error message is: "Cannot open > /usr/share/gcin/table/.kbm". Yes, there were some users experienced gcin installation problem on 16.04. One mentioned that you need to install language pack to make it work[1]. I also remember that I ever did something similar to make it work on on 16.04. But if it doesn't work for you, an easier way is to install gcin on 14.04, which must be very stable. [1] http://vk1968.blogspot.tw/2017/06/ubuntu-1604-64bit-install.html

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #21) > I give up to reproduce this bug in my environments. > > swu: > > Could you attach a log file at crash with following STR? > > 1. Open 3 tabs (if not enough, open more tabs) they all are about:home > 2. Open about:networking > 3. Choose "Logging" of the left pain > 4. Replace the input field of "Current Log File:" with a log file path where > you want to save them (you need to specify this with full path, so, > ~/foo.log isn't available), then, click "Set Log File". > 5. Replace the input field of "Current Log Modules:" with > "nsGtkIMModuleWidgets:5,KeymapWrapperWidgets:5,IMEStateManager:5,sync", > then, click "Set Log Modules" > 6. Click "Start Logging" and close the tab. > 7. Back to one of "about:home" tab. > 8. Type a character in the input field of "about:home" but don't commit it. > 9. Press Ctrl+PgDn to switch tabs until crashing. > > Then, attach the file "foo-main.<process number>" to this bug. > > > Please note that don't type any private information like passwords since all > key events are logged. I will get the log tomorrow.

This is the log as requested in comment 22. Version: Firefox nightly 57.0a1 20170903220032 Crash ID: https://crash-stats.mozilla.com/report/index/d971a173-1dbc-4a2d-bcb3-1213d0170904 My STR is a little different, otherwise it won't be reproducible even opening many tabs: 1. Enable session restore (Choose "Show your windows and tabs from last time" in about:preferences) 2. Open 3 tabs they all are about:home 3. Close Firefox 4. Open Firefox 5. Continue with step 2 in comment 22

Oops, I forgot to include "ContentCacheWidgets:5" into MOZ_LOG. However, perhaps, I got the reason. > [Main Thread]: I/IMEStateManager OnChangeFocus(aPresContext=0x0x7f5f4acbe000, aContent=0x0x7f5f3b7d18b0, aCause=CAUSE_UNKNOWN) > [Main Thread]: I/IMEStateManager OnChangeFocusInternal(aPresContext=0x0x7f5f4acbe000 (available: true), aContent=0x0x7f5f3b7d18b0 (TabParent=0x0x7f5f2baa6800), aAction={ mCause=CAUSE_UNKNOWN, mFocusChange=FOCUS_NOT_CHANGED }), sPresContext=0x0x7f5f4acbe000 (available: true), sContent=0x(nil), sWidget=0x0x7f5f4add2800 (available: true), sActiveTabParent=0x(nil), sActiveIMEContentObserver=0x(nil), sInstalledMenuKeyboardListener=false > [Main Thread]: D/IMEStateManager OnChangeFocusInternal(), will disable IME until new focused element (or document) in the child process will get focus actually > [Main Thread]: I/IMEStateManager SetIMEState(aState={ mEnabled=DISABLED, mOpen=DONT_CHANGE_OPEN_STATE }, aContent=0x0x7f5f3b7d18b0 (TabParent=0x0x7f5f2baa6800), aWidget=0x0x7f5f4add2800, aAction={ mCause=CAUSE_UNKNOWN, mFocusChange=GOT_FOCUS }, aOrigin=ORIGIN_CONTENT) > [Main Thread]: I/IMEStateManager SetInputContext(aWidget=0x0x7f5f4add2800, aInputContext={ mIMEState={ mEnabled=DISABLED, mOpen=DONT_CHANGE_OPEN_STATE }, mHTMLInputType="", mHTMLInputInputmode="", mActionHint="", mInPrivateBrowsing=false }, aAction={ mCause=CAUSE_UNKNOWN_CHROME, mAction=GOT_FOCUS }), sActiveTabParent=0x(nil) > [Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 SetInputContext(aCaller=0x0x7f5f4add2800, aContext={ mIMEState={ mEnabled=DISABLED }, mHTMLInputType= }) > [Main Thread]: D/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 DispatchCompositionStart(), FAILED, keydown event is dispatched > [Main Thread]: D/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 DispatchCompositionStart(), dispatching compositionstart... (mCompositionStart=0) > [Main Thread]: I/IMEStateManager DispatchCompositionEvent(aNode=0x0x7f5f3b7d18b0, aPresContext=0x0x7f5f4acbe000, aCompositionEvent={ mMessage=eCompositionStart, mNativeIMEContext={ mRawNativeIMEContext=0x7F5F512D18B0, mOriginProcessID=0x0 }, mWidget(0x0x7f5f4add2800)={ GetNativeIMEContext()={ mRawNativeIMEContext=0x7F5F512D18B0, mOriginProcessID=0x0 }, Destroyed()=false }, mFlags={ mIsTrusted=true, mPropagationStopped=false } }, aIsSynthesized=false), tabParent=0x7f5f2baa6800 > [Main Thread]: D/IMEStateManager DispatchCompositionEvent(), adding new TextComposition to the array > [Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 OnChangeCompositionNative(aContext=0x0x7f5f4ad7faa0) > [Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 GetCompositionString(aContext=0x0x7f5f4ad7faa0), aCompositionString="" > [Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 DispatchCompositionChangeEvent(aContext=0x0x7f5f4ad7faa0) > [Main Thread]: E/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 EnsureToCacheSelection(), FAILED, due to failure of query selection event > [Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 CreateTextRangeArray(aContext=0x0x7f5f4ad7faa0, aCompositionString="" (Length()=0)) > [Main Thread]: I/IMEStateManager DispatchCompositionEvent(aNode=0x0x7f5f3b7d18b0, aPresContext=0x0x7f5f4acbe000, aCompositionEvent={ mMessage=eCompositionChange, mNativeIMEContext={ mRawNativeIMEContext=0x7F5F512D18B0, mOriginProcessID=0x0 }, mWidget(0x0x7f5f4add2800)={ GetNativeIMEContext()={ mRawNativeIMEContext=0x7F5F512D18B0, mOriginProcessID=0x0 }, Destroyed()=false }, mFlags={ mIsTrusted=true, mPropagationStopped=false } }, aIsSynthesized=false), tabParent=0x7f5f2baa6800 > [Main Thread]: D/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 OnKeyEvent(), succeeded, filterThisEvent=false (isFiltered=false, mFilterKeyEvent=true), mCompositionState=CompositionChangeEventDispatched > [Main Thread]: D/KeymapWrapperWidgets 0x7f5f30e6df00 InitInputEvent, aModifierState=0x00000004, aInputEvent.mModifiers=0x0008 (Shift: FALSE, Control: TRUE, Alt: FALSE, Meta: FALSE, OS: FALSE, AltGr: FALSE, CapsLock: FALSE, NumLock: FALSE, ScrollLock: FALSE) > [Main Thread]: I/KeymapWrapperWidgets 0x7f5f30e6df00 InitKeyEvent, modifierState=0x00000004 aGdkKeyEvent={ type=GDK_KEY_PRESS, keyval=Page_Down(0xFF56), state=0x00000004, hardware_keycode=0x00000075, is_modifier=FALSE } aKeyEvent={ message=eKeyDown, isShift=FALSE, isControl=TRUE, isAlt=FALSE, isMeta=FALSE } > [Main Thread]: D/KeymapWrapperWidgets 0x7f5f30e6df00 InitInputEvent, aModifierState=0x00000004, aInputEvent.mModifiers=0x0008 (Shift: FALSE, Control: TRUE, Alt: FALSE, Meta: FALSE, OS: FALSE, AltGr: FALSE, CapsLock: FALSE, NumLock: FALSE, ScrollLock: FALSE) > [Main Thread]: I/KeymapWrapperWidgets 0x7f5f30e6df00 InitKeyEvent, modifierState=0x00000004 aGdkKeyEvent={ type=GDK_KEY_PRESS, keyval=Page_Down(0xFF56), state=0x00000004, hardware_keycode=0x00000075, is_modifier=FALSE } aKeyEvent={ message=eKeyPress, isShift=FALSE, isControl=TRUE, isAlt=FALSE, isMeta=FALSE } > [Main Thread]: D/KeymapWrapperWidgets 0x7f5f30e6df00 InitInputEvent, aModifierState=0x00000004, aInputEvent.mModifiers=0x0008 (Shift: FALSE, Control: TRUE, Alt: FALSE, Meta: FALSE, OS: FALSE, AltGr: FALSE, CapsLock: FALSE, NumLock: FALSE, ScrollLock: FALSE) > [Main Thread]: I/KeymapWrapperWidgets 0x7f5f30e6df00 InitKeyEvent, modifierState=0x00000004 aGdkKeyEvent={ type=GDK_KEY_PRESS, keyval=Page_Down(0xFF56), state=0x00000004, hardware_keycode=0x00000075, is_modifier=FALSE } aKeyEvent={ message=eKeyDown, isShift=FALSE, isControl=TRUE, isAlt=FALSE, isMeta=FALSE } > [Main Thread]: D/KeymapWrapperWidgets 0x7f5f30e6df00 InitInputEvent, aModifierState=0x00000004, aInputEvent.mModifiers=0x0008 (Shift: FALSE, Control: TRUE, Alt: FALSE, Meta: FALSE, OS: FALSE, AltGr: FALSE, CapsLock: FALSE, NumLock: FALSE, ScrollLock: FALSE) > [Main Thread]: I/KeymapWrapperWidgets 0x7f5f30e6df00 InitKeyEvent, modifierState=0x00000004 aGdkKeyEvent={ type=GDK_KEY_PRESS, keyval=Page_Down(0xFF56), state=0x00000004, hardware_keycode=0x00000075, is_modifier=FALSE } aKeyEvent={ message=eKeyPress, isShift=FALSE, isControl=TRUE, isAlt=FALSE, isMeta=FALSE } > [Main Thread]: I/IMEStateManager NotifyIME(aNotification={ mMessage=NOTIFY_IME_OF_BLUR }, aWidget=0x0x7f5f4add2800, aTabParent=0x0x7f5f2a8c4800), sFocusedIMEWidget=0x(nil), sActiveTabParent=0x0x7f5f2baa6800, sFocusedIMETabParent=0x(nil), IsSameProcess(aTabParent, sActiveTabParent)=false, IsSameProcess(aTabParent, sFocusedIMETabParent)=false > [Main Thread]: W/IMEStateManager NotifyIME(), WARNING, the received blur notification is ignored because it's not from current focused IME process > [Main Thread]: I/IMEStateManager SetInputContextForChildProcess(aTabParent=0x0x7f5f2baa6800, aInputContext={ mIMEState={ mEnabled=DISABLED, mOpen=DONT_CHANGE_OPEN_STATE }, mHTMLInputType="", mHTMLInputInputmode="", mActionHint="", mInPrivateBrowsing=false }, aAction={ mCause=CAUSE_UNKNOWN, mAction=LOST_FOCUS }), sPresContext=0x0x7f5f4acbe000 (available: true), sWidget=0x0x7f5f4add2800 (available: true), sActiveTabParent=0x0x7f5f2baa6800 > [Main Thread]: I/IMEStateManager SetInputContext(aWidget=0x0x7f5f4add2800, aInputContext={ mIMEState={ mEnabled=DISABLED, mOpen=DONT_CHANGE_OPEN_STATE }, mHTMLInputType="", mHTMLInputInputmode="", mActionHint="", mInPrivateBrowsing=false }, aAction={ mCause=CAUSE_UNKNOWN, mAction=LOST_FOCUS }), sActiveTabParent=0x0x7f5f2baa6800 > [Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f5f512d18b0 SetInputContext(aCaller=0x0x7f5f4add2800, aContext={ mIMEState={ mEnabled=DISABLED }, mHTMLInputType= }) Here is really strange. Looks like that when you start tabs with Ctrl+PageDown and a couple of tabs are changed, IMEStateManager sets IME enabled state to "disabled" until remote process will initialize the enabled state. However, gcin starts new composition even with disabled state. It's really wired behavior...

(In reply to Shian-Yow Wu [:swu] (56 Regression Engineering support) from comment #24) > Version: Firefox nightly 57.0a1 20170903220032 > Crash ID: > https://crash-stats.mozilla.com/report/index/d971a173-1dbc-4a2d-bcb3- > 1213d0170904 Oops, but you hit different crash bug, that is bug 1396302.

Here is the log with "sync,ContentCacheWidgets:5,nsGtkIMModuleWidgets:5,IMEStateManager:5,KeymapWrapperWidgets:5" Yes, I hit bug 1396302. Sound like a good news since we have a way to reproduce bug 1396302?

(In reply to Shian-Yow Wu [:swu] (56 Regression Engineering support) from comment #27) > Sound like a good news since we have a way to > reproduce bug 1396302? Unfortunately, it's too odd behavior. In other words, we need to kill the odd path which found from your log. So, I cannot write automated test for it...

Well, I understand, it's not gcin's odd behavior, it's our bug. (But the behavior is a little bit odd, though.) gcin tries to start composition even if user doesn't input any text. Therefore, it tries to start composition with Ctrl+PageDown. However, it causes making the IME state disabled but IMContextWrapper::DispatchStartComposition() keeps trying to dispatch composition. So, it should check if focus is changed during composition.

Do you reproduce this bug with this trybuild? https://queue.taskcluster.net/v1/task/fdmKPRjIQYOTNPqbiGJdgw/runs/0/artifacts/public/build/target.tar.bz2

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #30) > Do you reproduce this bug with this trybuild? > https://queue.taskcluster.net/v1/task/fdmKPRjIQYOTNPqbiGJdgw/runs/0/ > artifacts/public/build/target.tar.bz2 No longer reproducible with this trybuild!

(In reply to Shian-Yow Wu [:swu] (56 Regression Engineering support) from comment #31) > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #30) > > Do you reproduce this bug with this trybuild? > > https://queue.taskcluster.net/v1/task/fdmKPRjIQYOTNPqbiGJdgw/runs/0/ > > artifacts/public/build/target.tar.bz2 > > No longer reproducible with this trybuild! Thank you!

Comment on attachment 8904412 [details] Bug 1387357 - IMContextWrapper::DispatchCompositionStart() should stop dispatching eCompositionStart if dispatching preceding eKeyDown event causes changing active IM context https://reviewboard.mozilla.org/r/176222/#review181176

Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/4249740f0664 IMContextWrapper::DispatchCompositionStart() should stop dispatching eCompositionStart if dispatching preceding eKeyDown event causes changing active IM context r=m_kato

Please request Beta approval on this when you get a chance.

Comment on attachment 8904412 [details] Bug 1387357 - IMContextWrapper::DispatchCompositionStart() should stop dispatching eCompositionStart if dispatching preceding eKeyDown event causes changing active IM context Approval Request Comment [Feature/Bug causing the regression]: Regression of bug 1377672. [User impact if declined]: Some IME users of Linux may meet this crash if they switch active tab with shortcut key when an editable element like <input> has focus. [Is this code covered by automated tests?]: No. We don't have automated test API of testing native IME event handler. [Has the fix been verified in Nightly?]: Not yet, but before review, it's confirmed with patched build (try-build). [Needs manual test from QE? If yes, steps to reproduce]: No. [List of other uplifts needed for the feature/fix]: Needs patch for bug 1396302 since according to the reporter, the STR may hit bug 1396302. (comment 24) [Is the change risky?]: No. [Why is the change risky/not risky?]: Just making native IME event handler stop dispatching compositionstart if preceding keydown event causes IME disabled. [String changes made/needed]: No.

Comment on attachment 8904412 [details] Bug 1387357 - IMContextWrapper::DispatchCompositionStart() should stop dispatching eCompositionStart if dispatching preceding eKeyDown event causes changing active IM context Fix for a regression in 56, try build looks ok, so let's take this for beta 10.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #38) > [Needs manual test from QE? If yes, steps to reproduce]: > No. Per Masayuki's assessment on manual testing needs, setting the qe-verify flag to -.