Bug 538918 - Move Init() above mutex unlock - attempted test hang fix.
--- a/ipc/glue/WindowsMessageLoop.cpp
+++ b/ipc/glue/WindowsMessageLoop.cpp
@@ -599,21 +599,21 @@ RPCChannel::IsMessagePending()
return false;
}
bool
SyncChannel::WaitForNotify()
{
mMutex.AssertCurrentThreadOwns();
- MutexAutoUnlock unlock(mMutex);
-
// Initialize global objects used in deferred messaging.
Init();
+ MutexAutoUnlock unlock(mMutex);
+
if (++gEventLoopDepth == 1) {
NS_ASSERTION(!gNeuteredWindows, "Should only set this once!");
gNeuteredWindows = new nsAutoTArray<HWND, 20>();
NS_ASSERTION(gNeuteredWindows, "Out of memory!");
}
// Setup deferred processing of native events while we wait for a response.
NS_ASSERTION(!SyncChannel::IsPumpingMessages(),
@@ -707,21 +707,21 @@ SyncChannel::WaitForNotify()
return true;
}
bool
RPCChannel::WaitForNotify()
{
mMutex.AssertCurrentThreadOwns();
- MutexAutoUnlock unlock(mMutex);
-
// Initialize global objects used in deferred messaging.
Init();
+ MutexAutoUnlock unlock(mMutex);
+
// IsSpinLoopActive indicates modal UI is being displayed in a plugin. Drop
// down into the spin loop until all modal loops end. If SpinInternalEventLoop
// returns true, the out-call response we were waiting on arrived, or we
// received an in-call request from child, so return from WaitForNotify.
// We'll step back down into the spin loop on the next WaitForNotify call.
// If the spin loop returns false, the child's modal loop has ended, so
// drop down into "normal" deferred processing until the next reply is
// received. Note, spin loop can cause reentrant race conditions, which