Bug 1110615 - Fix inheriting problem for blobs (r=sicking)

caps/nsScriptSecurityManager.cpp

@@ -976,7 +976,7 @@ nsScriptSecurityManager::CreateCodebasePrincipal(nsIURI* aURI, uint32_t aAppId,
     if (uriPrinc) {
         nsCOMPtr<nsIPrincipal> principal;
         uriPrinc->GetPrincipal(getter_AddRefs(principal));
-        if (!principal || principal == mSystemPrincipal) {
+        if (!principal) {
             return CallCreateInstance(NS_NULLPRINCIPAL_CONTRACTID, result);
         }
 

dom/base/nsHostObjectProtocolHandler.cpp

@@ -523,7 +523,7 @@ nsHostObjectProtocolHandler::NewChannel2(nsIURI* uri,
                                 uri,
                                 stream,
                                 info->mPrincipal,
-                                nsILoadInfo::SEC_FORCE_INHERIT_PRINCIPAL,
+                                nsILoadInfo::SEC_NORMAL,
                                 nsIContentPolicy::TYPE_OTHER);
 
   NS_ENSURE_SUCCESS(rv, rv);

netwerk/base/public/nsNetUtil.h

@@ -239,19 +239,8 @@ NS_NewChannelInternal(nsIChannel**           outChannel,
     NS_ENSURE_SUCCESS(rv, rv);
   }
 
-  // Some channels might already have a loadInfo attached at this
-  // point (see bug 1104623). We have to make sure to update
-  // security flags in such cases before we set the loadinfo.
-  // Once bug 1087442 lands, this problem disappears because we
-  // attach the loadinfo in each individual protocol handler.
-  nsCOMPtr<nsILoadInfo> loadInfo;
-  channel->GetLoadInfo(getter_AddRefs(loadInfo));
-  if (loadInfo) {
-    aSecurityFlags |= loadInfo->GetSecurityFlags();
-  }
-
   // create a new Loadinfo with the potentially updated securityFlags
-  loadInfo =
+  nsCOMPtr<nsILoadInfo> loadInfo =
     new mozilla::LoadInfo(aRequestingPrincipal, aTriggeringPrincipal,
                           aRequestingNode, aSecurityFlags,
                           aContentPolicyType, aBaseURI);