Bug 1110615 - Fix inheriting problem for blobs (r=sicking)
authorChristoph Kerschbaumer <mozilla@christophkerschbaumer.com>
Fri, 12 Dec 2014 09:03:47 -0800
changeset 219426 2c906f99509740d3af39e9e63e1f50f6b387f44d
parent 219425 4c65234c3ead6cadcf1d8807549e8f1df36ea16e
child 219427 6d556f4cd5a79fe2820579bab566c232df65d67e
push id52830
push usermozilla@christophkerschbaumer.com
push dateFri, 12 Dec 2014 17:20:37 +0000
treeherdermozilla-inbound@2e0a0c0d7685 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewerssicking
bugs1110615
milestone37.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1110615 - Fix inheriting problem for blobs (r=sicking)
caps/nsScriptSecurityManager.cpp
dom/base/nsHostObjectProtocolHandler.cpp
netwerk/base/public/nsNetUtil.h
--- a/caps/nsScriptSecurityManager.cpp
+++ b/caps/nsScriptSecurityManager.cpp
@@ -971,17 +971,17 @@ nsScriptSecurityManager::CreateCodebaseP
     // I _think_ it's safe to not create null principals here based on aURI.
     // At least all the callers would do the right thing in those cases, as far
     // as I can tell.  --bz
 
     nsCOMPtr<nsIURIWithPrincipal> uriPrinc = do_QueryInterface(aURI);
     if (uriPrinc) {
         nsCOMPtr<nsIPrincipal> principal;
         uriPrinc->GetPrincipal(getter_AddRefs(principal));
-        if (!principal || principal == mSystemPrincipal) {
+        if (!principal) {
             return CallCreateInstance(NS_NULLPRINCIPAL_CONTRACTID, result);
         }
 
         principal.forget(result);
 
         return NS_OK;
     }
 
--- a/dom/base/nsHostObjectProtocolHandler.cpp
+++ b/dom/base/nsHostObjectProtocolHandler.cpp
@@ -518,17 +518,17 @@ nsHostObjectProtocolHandler::NewChannel2
   nsresult rv = blob->GetInternalStream(getter_AddRefs(stream));
   NS_ENSURE_SUCCESS(rv, rv);
 
   nsCOMPtr<nsIChannel> channel;
   rv = NS_NewInputStreamChannel(getter_AddRefs(channel),
                                 uri,
                                 stream,
                                 info->mPrincipal,
-                                nsILoadInfo::SEC_FORCE_INHERIT_PRINCIPAL,
+                                nsILoadInfo::SEC_NORMAL,
                                 nsIContentPolicy::TYPE_OTHER);
 
   NS_ENSURE_SUCCESS(rv, rv);
 
   nsString type;
   blob->GetType(type);
 
   if (blob->IsFile()) {
--- a/netwerk/base/public/nsNetUtil.h
+++ b/netwerk/base/public/nsNetUtil.h
@@ -234,29 +234,18 @@ NS_NewChannelInternal(nsIChannel**      
   if (aLoadFlags != nsIRequest::LOAD_NORMAL) {
     // Retain the LOAD_REPLACE load flag if set.
     nsLoadFlags normalLoadFlags = 0;
     channel->GetLoadFlags(&normalLoadFlags);
     rv = channel->SetLoadFlags(aLoadFlags | (normalLoadFlags & nsIChannel::LOAD_REPLACE));
     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);
   if (!loadInfo) {
     return NS_ERROR_UNEXPECTED;
   }
   channel->SetLoadInfo(loadInfo);