Closed Bug 1432205 Opened 5 years ago Closed 2 years ago

Consider requiring the creation of a LoadInfo in nsIOService::NewChannelFromURIWithProxyFlagsInternal()


(Core :: Networking, enhancement, P3)




Tracking Status
firefox78 --- fixed


(Reporter: bkelly, Assigned: ckerschb)



(Whiteboard: [necko-triaged])


(1 file)

In bug 1231211 I am moving some code from nsIOService's NewChannelFromURIWithProxyFlags2() into a NewChannelFromProxyFlagsInternal().  While reviewing this Valentin noticed the comment is out of date here:

It seems like there is some code here trying to accomodate old addons and an API that no longer exists.  We should consider trying to make this code require the creation of a LoadInfo
Priority: -- → P3
Whiteboard: [necko-triaged]
There is more incorrect comment/logic below the code referenced in comment 0.
    // TYPE_DOCUMENT loads don't require a loadingNode or principal, but other
    // types do.
    if (aLoadingNode || aLoadingPrincipal ||
        aContentPolicyType == nsIContentPolicy::TYPE_DOCUMENT) {
      nsCOMPtr<nsINode> loadingNode(do_QueryInterface(aLoadingNode));
      loadInfo = new LoadInfo(aLoadingPrincipal,

This claim about nullability of loading node and principal is also present in the LoadingNode documentation:
   * For top-level loads, and for loads originating from workers, the
   * LoadingNode is null. If the LoadingNode is non-null, then the
   * LoadingPrincipal is the principal of the LoadingNode.
   ... For top-level loads, the
   * LoadingPrincipal is null. For all loads except top-level loads
   * the LoadingPrincipal is never null.

Despite the documentation, the implementation fails when the node and the principal are both null:
LoadInfo::LoadInfo(nsIPrincipal* aLoadingPrincipal,
                   nsIPrincipal* aTriggeringPrincipal,
                   nsINode* aLoadingContext,
  : mLoadingPrincipal(aLoadingContext ?
                        aLoadingContext->NodePrincipal() : aLoadingPrincipal)

#ifdef DEBUG
  // TYPE_DOCUMENT loads initiated by javascript tests will go through
  // nsIOService and use the wrong constructor.  Don't enforce the
  // !TYPE_DOCUMENT check in those cases
  bool skipContentTypeCheck = false;
  skipContentTypeCheck = Preferences::GetBool("network.loadinfo.skip_type_assertion");

(the DEBUG check was added in bug 1105556)

Apparently a different LoadInfo constructor should be used for TYPE_DOCUMENT:

The problem in this code path can be demonstrated as follows:

1. Enable (e.g. via the checkbox at about:debugging).
2. Run the following from the global JS console:""), null, 0, null, null, null, 0, Components.interfaces.nsIContentPolicy.TYPE_DOCUMENT);

Expected result: a nsIChannel

Actual result: crash (nullptr dereference on release builds; I guess that on debug builds the assertion would be triggered).
Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
mozilla::net::LoadInfo::LoadInfo (this=0x7fffb7152300, aLoadingPrincipal=0x0, aTriggeringPrincipal=<optimized out>, aLoadingContext=0x0, aSecurityFlags=<optimized out>, aContentPolicyType=6, aLoadingClientInfo=..., aController=...)
    at /path/to/gecko/netwerk/base/LoadInfo.cpp:247
247       mOriginAttributes = mLoadingPrincipal->OriginAttributesRef();
(gdb) p mLoadingPrincipal
$1 = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}
Assignee: nobody → ckerschb
Pushed by
Always require the creation of a LoadInfo in nsIOService::NewChannelFromURIWithProxyFlagsInternal. r=valentin,necko-reviewers
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
Blocks: 1716556
You need to log in before you can comment on or make changes to this bug.