ChannelWrapper::IsSystemLoad has the following logic:

1. If a loadingPrincipal is available, return whether that is the system principal.
2. Otherwise, if a browsing context is unavailable or if it is the top level, return false.
3. Otherwise, if principalToInherit is available, return whether it is the system principal.
4. Otherwise, if triggeringPrincipal is available, return whether it is the system principal.
5. Otherwise return false.

The logic above is misleading. Steps 3-5 can be skipped.

• loadingPrincipal is always set for non-top-level loads (source: documentation of loadingPrincipal in nsILoadInfo.idl), so after step 1 we only have top-level loads.
• Step 2 consists of two steps:
  • !bc - in theory, it is possible for the BrowsingContext to have disappeared at the time of checking loadInfo.browsingContext, so this check is reasonable.
  • bc->IsTop() - since we only have a top-level load at this point, we would return unconditionally now.
• The remaining steps are skipped, but here is my remaining analysis for completeness:
• Step 3: principalToInherit is always null for document requests and might be non-null for document requests. I can imagine the principal being inherit for about:blank and (when opted in via pref) data:-URL requests. But these don't pass through WebRequest (data:-URL support was removed in bug 1631933).
• Step 4: triggeringPrincipal can be a system principal for user-triggered top-level navigations. But we do really want to allow interception of these in the webRequest API (bug 1318800).

So, clearly, ChannelWrapper::IsSystemLoad() can be simplified to only check whether the loading principal is a system principal.

After the simplification and further analysis, it appears that ChannelWrapper::IsSystemLoad() can be removed and its only use be replaced with ChannelWrapper::CanModify(). For details, see the last paragraph of bug 1825882.

https://hg.mozilla.org/mozilla-central/rev/9f498a41967b