I'm not sure if this is site specific, but it happens reliably for me on Jobvite: https://hire.jobvite.com/login/jvlogin.aspx Lastpass does not show the auto-fill icons on the login fields here. So I right click the password field, select Lastpass, select Autofill, and select my Jobvite profile. Here is a backtrace from the crash: #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007f63b3f0c1a1 in _L_lock_1022 () from /lib64/libpthread.so.0 #2 0x00007f63b3f0c142 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7f63a4c5cdf0) at ../nptl/pthread_mutex_lock.c:134 #3 0x00007f63b38dda09 in PR_Lock (lock=0x7f63a4c5cdf0) at /home/jack/src/mozilla-central/nsprpub/pr/src/pthreads/ptsynch.c:177 #4 0x00007f63afe0fc13 in Lock (this=<optimized out>) at ../../dist/include/mozilla/Monitor.h:35 #5 MonitorAutoLock (aMonitor=..., this=0x7fffae7cc7b8) at ../../dist/include/mozilla/Monitor.h:78 #6 mozilla::ipc::MessageChannel::Send (this=0x7f63a4c1d090, aMsg=aMsg@entry=0x7f6374aeadf0) at /home/jack/src/mozilla-central/ipc/glue/MessageChannel.cpp:461 #7 0x00007f63afe694a9 in mozilla::dom::PCrashReporterChild::SendAppendAppNotes (this=this@entry=0x7f63a4cb1670, data=...) at /home/jack/src/mozilla-central/obj-x86_64-unknown-linux-gnu/ipc/ipdl/PCrashReporterChild.cpp:84 #8 0x00007f63b0fdaf22 in CrashReporter::AppendAppNotesToCrashReport (data=...) at /home/jack/src/mozilla-central/toolkit/crashreporter/nsExceptionHandler.cpp:1728 #9 0x00007f63afbf009f in NS_DebugBreak (aSeverity=<optimized out>, aStr=0x7f63b19d122c "sync messages forbidden while handling urgent message", aExpr=0x0, aFile=0x7f63b19d090a "/home/jack/src/mozilla-central/ipc/glue/MessageChannel.cpp", aLine=1826) at /home/jack/src/mozilla-central/xpcom/base/nsDebugImpl.cpp:419 #10 0x00007f63afe0e58a in mozilla::ipc::MessageChannel::DebugAbort (this=this@entry=0x7f63a4c1d090, file=file@entry=0x7f63b19d090a "/home/jack/src/mozilla-central/ipc/glue/MessageChannel.cpp", line=line@entry=626, cond=cond@entry=0x7f63b19d1262 "!DispatchingUrgentMessage()", why=why@entry=0x7f63b19d122c "sync messages forbidden while handling urgent message", reply=reply@entry=false) at /home/jack/src/mozilla-central/ipc/glue/MessageChannel.cpp:1826 #11 0x00007f63afe0ffec in mozilla::ipc::MessageChannel::Send (this=0x7f63a4c1d090, aMsg=0x7f63746c7550, aReply=aReply@entry=0x7fffae7cce00) at /home/jack/src/mozilla-central/ipc/glue/MessageChannel.cpp:626 #12 0x00007f63afe4a2db in mozilla::dom::PBrowserChild::SendEndIMEComposition (this=0x7f639558f920, cancel=@0x7fffae7cce6c: false, composition=composition@entry=0x7fffae7ccf90) at /home/jack/src/mozilla-central/obj-x86_64-unknown-linux-gnu/ipc/ipdl/PBrowserChild.cpp:544 #13 0x00007f63b08a0429 in mozilla::widget::PuppetWidget::IMEEndComposition (this=0x7f6395bea700, aCancel=aCancel@entry=false) at /home/jack/src/mozilla-central/widget/xpwidgets/PuppetWidget.cpp:391 #14 0x00007f63b08a05a9 in mozilla::widget::PuppetWidget::NotifyIMEOfFocusChange (this=0x7f6395bea700, aFocus=false) at /home/jack/src/mozilla-central/widget/xpwidgets/PuppetWidget.cpp:494 #15 0x00007f63b07364b9 in mozilla::IMEContentObserver::UnregisterObservers (this=this@entry=0x7f63761fd350, aPostEvent=aPostEvent@entry=false) at /home/jack/src/mozilla-central/dom/events/IMEContentObserver.cpp:244 #16 0x00007f63b073670b in mozilla::IMEContentObserver::Destroy (this=0x7f63761fd350) at /home/jack/src/mozilla-central/dom/events/IMEContentObserver.cpp:270 #17 0x00007f63b073679b in mozilla::IMEStateManager::DestroyIMEContentObserver () at /home/jack/src/mozilla-central/dom/events/IMEStateManager.cpp:1100 #18 0x00007f63b0737807 in mozilla::IMEStateManager::OnChangeFocusInternal (aPresContext=0x7f63939e3800, aContent=aContent@entry=0x0, aAction=..., aAction@entry=...) at /home/jack/src/mozilla-central/dom/events/IMEStateManager.cpp:396 #19 0x00007f63b073783e in mozilla::IMEStateManager::OnChangeFocus (aPresContext=<optimized out>, aContent=aContent@entry=0x0, aCause=aCause@entry=mozilla::widget::InputContextAction::CAUSE_UNKNOWN) at /home/jack/src/mozilla-central/dom/events/IMEStateManager.cpp:363 #20 0x00007f63b02fbfba in nsFocusManager::Blur (this=this@entry=0x7f63a4c72970, aWindowToClear=0x7f6395590820, aAncestorWindowToFocus=0x0, aIsLeavingDocument=<optimized out>, aAdjustWidgets=aAdjustWidgets@entry=true) at /home/jack/src/mozilla-central/dom/base/nsFocusManager.cpp:1537 #21 0x00007f63b02fd996 in nsFocusManager::SetFocusInner (this=0x7f63a4c72970, aNewContent=<optimized out>, aFlags=aFlags@entry=0, aFocusChanged=aFocusChanged@entry=true, aAdjustWidget=aAdjustWidget@entry=true) at /home/jack/src/mozilla-central/dom/base/nsFocusManager.cpp:1241 #22 0x00007f63b02fdb6b in nsFocusManager::SetFocus (this=<optimized out>, aElement=<optimized out>, aFlags=0) at /home/jack/src/mozilla-central/dom/base/nsFocusManager.cpp:443 #23 0x00007f63b09c7226 in nsGenericHTMLElement::Focus (this=0x7f63a4c5cdf0, this@entry=0x7f638caabc40, aError=...) at /home/jack/src/mozilla-central/content/html/content/src/nsGenericHTMLElement.cpp:2613 #24 0x00007f63b09a1e27 in mozilla::dom::HTMLInputElement::Focus (this=0x7f638caabc40, aError=...) at /home/jack/src/mozilla-central/content/html/content/src/HTMLInputElement.cpp:3138 #25 0x00007f63b0448633 in mozilla::dom::HTMLElementBinding::focus (cx=0x7f63a4c80a80, obj=..., self=<optimized out>, args=...) at /home/jack/src/mozilla-central/obj-x86_64-unknown-linux-gnu/dom/bindings/HTMLElementBinding.cpp:771 #26 0x00007f63b06bc745 in mozilla::dom::GenericBindingMethod (cx=0x7f63a4c80a80, argc=<optimized out>, vp=<optimized out>) at /home/jack/src/mozilla-central/dom/bindings/BindingUtils.cpp:2484 #27 0x00007f63b181cfe8 in CallJSNative (args=..., native= 0x7f63b06bc610 <mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*)>, cx=0x7f63a4c80a80) at /home/jack/src/mozilla-central/js/src/jscntxtinlines.h:231 #28 js::Invoke (cx=cx@entry=0x7f63a4c80a80, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /home/jack/src/mozilla-central/js/src/vm/Interpreter.cpp:481 #29 0x00007f63b181d491 in js::Invoke (cx=cx@entry=0x7f63a4c80a80, thisv=..., fval=..., argc=0, argv=<optimized out>, rval=...) at /home/jack/src/mozilla-central/js/src/vm/Interpreter.cpp:537 #30 0x00007f63b17012c2 in js::DirectProxyHandler::call ( this=this@entry=0x7f63b37fc0e0 <js::CrossCompartmentWrapper::singleton>, cx=cx@entry=0x7f63a4c80a80, proxy=..., proxy@entry=..., args=...) at /home/jack/src/mozilla-central/js/src/jsproxy.cpp:484 #31 0x00007f63b17b8fd1 in js::CrossCompartmentWrapper::call ( this=0x7f63b37fc0e0 <js::CrossCompartmentWrapper::singleton>, cx=0x7f63a4c80a80, wrapper=..., args=...) at /home/jack/src/mozilla-central/js/src/jswrapper.cpp:452 #32 0x00007f63b1745519 in call (args=..., proxy=..., cx=0x7f63a4c80a80) at /home/jack/src/mozilla-central/js/src/jsproxy.cpp:2535 #33 js::proxy_Call (cx=cx@entry=0x7f63a4c80a80, argc=<optimized out>, vp=<optimized out>) at /home/jack/src/mozilla-central/js/src/jsproxy.cpp:2930 #34 0x00007f63b181d12f in CallJSNative (args=..., native= 0x7f63b1745450 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, cx=0x7f63a4c80a80) at /home/jack/src/mozilla-central/js/src/jscntxtinlines.h:231 This is on a build I compiled from mozilla-central on 8/27/2014.

I wish we had a full stack; my suspicion is that we end up trying to send synchronous IME messages while executing CPOW operations, hence the assertion in frame 10.

Comment on attachment 8487247 [details] full backtrace of all threads Yep, there's a CPOW operation occurring in frame 39. Is this something that should be addressed by the people working on e10s IME support?

me or masayuki. Is this reproduce this when using LastPass with e10s mode? EndIMEComposition method on IPC implements on Android XUL era. I think that we should send notifications (REQUEST_TO_COMMIT_COMPOSITION and REQUEST_TO_CANCEL_COMPOSITION) to parent process simply?

(In reply to Makoto Kato (:m_kato) from comment #4) > I think that we should send notifications (REQUEST_TO_COMMIT_COMPOSITION and > REQUEST_TO_CANCEL_COMPOSITION) to parent process simply? I guess that we need more work at doing it. Some callers may assume commit or cancel occurs synchronously. For example, see this hack: http://mxr.mozilla.org/mozilla-central/source/dom/events/IMEStateManager.cpp#315 I think that we should add an API to commit or cancel composition to TextComposition. If widget doesn't perform it synchronously, it should synthesize composition events manually and consumes the delayed events for the request. Anyway, this is useful for GTK widget. I'll file a bug and create it.

(In reply to Makoto Kato (:m_kato) from comment #4) > I think that we should send notifications (REQUEST_TO_COMMIT_COMPOSITION and > REQUEST_TO_CANCEL_COMPOSITION) to parent process simply? By the fix of bug 1065835, TextComposition handles the both requests and guarantees commit or canceling occurs synchronously. Therefore, these requests now useful and stable even when they are requested by content process.

I.e., when PuppetWidget::NotifyIME(REQUEST_TO_COMMIT_COMPOSITION) or PuppetWidget::NotifyIME(REQUEST_TO_CANCEL_COMPOSITION) is called, it should redirect the request to the parent process and doesn't need to care synchronous commit by itself because it's managed by TextComposition now.

Jack, could you reproduce this on the latest Nightly? I cannot. Also, we need clean up REQUEST_TO_COMMIT_COMPOSITON and REQUEST_TO_CANCEL_COMPOSITION even if this crash doesn't occur.

It does indeed appear fixed.

Thanks. Also I will stop IPC call on IME blur of child process's widget by bug 1121313. After that, we will not hit this issue. resolved WFM due to not repro.