See attached stacks. I had just closed a tab when this showed up.

note, chrome was still responsive (the thread's in sitting in WinUtils::WaitForMessage).

This patch takes care of a few issues that could cause WaitForInit() to get stuck indefinitely. SetupBridge could result in a hang if we reused an existing PluginModuleChromeParent, since we would end up waiting for NP_Initialize to happen when it never would (as it is not executed in this case). WaitForInit was modified to check for conditions that would require us to break out if a failure condition occurred while processing IPC events. Finally the code for handling errors in streams was cleaned up to ensure that failures are better handled.

Comment on attachment 8566381 [details] [diff] [review] Patch (r1) Review of attachment 8566381 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/plugins/ipc/PluginAsyncSurrogate.cpp @@ +450,5 @@ > dom::ContentChild* cp = dom::ContentChild::GetSingleton(); > mozilla::ipc::MessageChannel* contentChannel = cp->GetIPCChannel(); > MOZ_ASSERT(contentChannel); > while (!mParent->mNPInitialized) { > + if (mParent->mShutdown) { nit - add a comment here and below explaining the early return / failure.

Added comments. Carrying forward r+.

Stupid bustage fix: https://hg.mozilla.org/integration/mozilla-inbound/rev/c07df64140ae

https://hg.mozilla.org/mozilla-central/rev/92279670ec95 https://hg.mozilla.org/mozilla-central/rev/c07df64140ae