Bug 874502 - Part 6: Remove IsCallerChrome path for tearing down windows synchronously. r=bzbarsky, a=lsblakk
authorBobby Holley <bobbyholley@gmail.com>
Tue, 17 Sep 2013 17:45:48 -0400
changeset 160334 e1bed78a75d62bf65d30e6309fadf960a3a4e04f
parent 160333 37bb3ce8167c0cf794d71ca9de5f6d76d9d03b66
child 160335 10c8613564e30a87a54b15e4cc7f060f505c94ae
push id2961
push userlsblakk@mozilla.com
push dateMon, 28 Oct 2013 21:59:28 +0000
treeherdermozilla-beta@73ef4f13486f [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersbzbarsky, lsblakk
bugs874502
milestone26.0a2
Bug 874502 - Part 6: Remove IsCallerChrome path for tearing down windows synchronously. r=bzbarsky, a=lsblakk
dom/base/nsGlobalWindow.cpp
--- a/dom/base/nsGlobalWindow.cpp
+++ b/dom/base/nsGlobalWindow.cpp
@@ -7260,32 +7260,24 @@ nsGlobalWindow::FinalClose()
   // This stuff is non-sensical but incredibly fragile. The reasons for the
   // behavior here don't make sense today and may not have ever made sense,
   // but various bits of frontend code break when you change them. If you need
   // to fix up this behavior, feel free to. It's a righteous task, but involves
   // wrestling with various download manager tests, frontend code, and possible
   // broken addons. The chrome tests in toolkit/mozapps/downloads are a good
   // testing ground.
   //
-  // Here are some quirks that the test suite depends on:
-  //
-  // * When chrome code executes |win|.close(), that close happens immediately,
-  //   along with the accompanying "domwindowclosed" notification. But _only_ if
-  //   |win|'s JSContext is not at the top of the stack. If it is, the close
-  //   _must not_ happen immediately.
-  //
-  // * If |win|'s JSContext is at the top of the stack, we must complete _two_
-  //   round-trips to the event loop before the call to ReallyCloseWindow. This
-  //   allows setTimeout handlers that are set after FinalClose() is called to
-  //   run before the window is torn down.
+  // In particular, if |win|'s JSContext is at the top of the stack, we must
+  // complete _two_ round-trips to the event loop before the call to
+  // ReallyCloseWindow. This allows setTimeout handlers that are set after
+  // FinalClose() is called to run before the window is torn down.
   bool indirect = GetContextInternal() && // Occasionally null. See bug 877390.
                   (nsContentUtils::GetCurrentJSContext() ==
                    GetContextInternal()->GetNativeContext());
-  if ((!indirect && nsContentUtils::IsCallerChrome()) ||
-      NS_FAILED(nsCloseEvent::PostCloseEvent(this, indirect))) {
+  if (NS_FAILED(nsCloseEvent::PostCloseEvent(this, indirect))) {
     ReallyCloseWindow();
   } else {
     mHavePendingClose = true;
   }
 
   return NS_OK;
 }