Bug 615355 - Remove the assertion at the beginning of nsChromeRegistry::Init; r=bsmedberg a=bzbarsky
authorEhsan Akhgari <ehsan@mozilla.com>
Tue, 30 Nov 2010 16:32:55 -0500
changeset 58440 98fa9c0cff7a396517d302c4960211fdddc13aec
parent 58439 4dffc64da8694b0ebe9386b23994d91128dd3798
child 58441 7c282eb45b9b72c1b911f6c10fdb776bd7dda82b
push id1
push usershaver@mozilla.com
push dateTue, 04 Jan 2011 17:58:04 +0000
reviewersbsmedberg, bzbarsky
bugs615355
milestone2.0b8pre
Bug 615355 - Remove the assertion at the beginning of nsChromeRegistry::Init; r=bsmedberg a=bzbarsky
chrome/src/nsChromeRegistry.cpp
--- a/chrome/src/nsChromeRegistry.cpp
+++ b/chrome/src/nsChromeRegistry.cpp
@@ -172,23 +172,16 @@ nsChromeRegistry::GetService()
   }
   NS_ADDREF(gChromeRegistry);
   return gChromeRegistry;
 }
 
 nsresult
 nsChromeRegistry::Init()
 {
-  // Check to see if necko and the JAR protocol handler are registered yet
-  // if not, somebody is doing work during XPCOM registration that they
-  // shouldn't be doing. See bug 292549, where JS components are trying
-  // to call Components.utils.import("chrome:///") early in registration
-  NS_ASSERTION(nsCOMPtr<nsIIOService>(mozilla::services::GetIOService()),
-               "I/O service not registered or available early enough?");
-
   if (!mOverrideTable.Init())
     return NS_ERROR_FAILURE;
 
   // This initialization process is fairly complicated and may cause reentrant
   // getservice calls to resolve chrome URIs (especially locale files). We
   // don't want that, so we inform the protocol handler about our existence
   // before we are actually fully initialized.
   gChromeRegistry = this;