TL;DR: Some channel.canModify checks in WebRequest.jsm can be dropped. Independently, ChannelWrapper::IsSystemLoad() can be removed and its only caller in ChannelWrapper::Matches can be replaced with ChannelWrapper::CanModify().

ChannelWrapper::IsSystemLoad() has only one caller, in ChannelWrapper::matches when isProxy=false. This covers exactly all webRequest event listeners (except webRequest.onAuthRequired which has isProxy=true) (the only other caller of matches is the proxy.onRequest implementation, but that also sets isProxy=true).

That logic in ChannelWrapper::matches prevents system requests and restricted domains from matching non-proxy webRequest listeners. This exact logic is also implemented in ChannelWrapper::CanModify, which has the following callers:

• applyChanges: ignore webRequest listener responses for non-proxy webRequest listeners
  • The caller, i.e. runChannelListener only includes results if channel.canModify || opts.isProxy, so !channel.canModify is only true if opts.isProxy is set AND ChannelWrapper::Matches() accepted (i.e. the extension has the "proxy" permission). This is only potentially the case in the onAuthRequired handler.
• runChannelListener: exclude requestBody from webRequest listener details.
  • Note that webRequest.onAuthRequired cannot register the requestBody extraInfoSpec, so in practice this is only for non-proxy webRequest listeners.
• runChannelListener: accept listener response if channel.canModify || data.isProxy
  • Since ChannelWrapper::matches already runs exactly the same logic as canModify for non-proxy requests, the condition basically boils down to "isNotProxy || isProxy". In other words, this check can be removed.

All together, the conclusion is that the channel.canModify check can be replaced with !opts.isProxy

The above logic is only true if the aExtension parameter of ChannelWrapper::matches is set. This is the case for all m-c code: ProxyChannelFilter.jsm always passes a policy, and WebRequest.jsm always has a policy since it is passed by ext-webRequest.js (FYI: extension.policy is always non-void).

The only case where WebRequest.jsm could be receiving a listener without an extension parameter is when the module is directly used. Other than three WebRequest module tests, m-c has no such usage. In theory, a privileged extension could import WebRequest.jsm and use it directly, but in that case the extension is privileged and it can already modify any request. So, even if we consider the (unlikely) case of aExtension being void, the proposed change would at most cause previously-ignored WebRequest results to not be ignored. If this behavioral change is undesirable (I don't see why), we can replace channel.canModify with !opts.extension.

With the WebRequest.jsm usage of ChannelWrapper::CanModify having been removed, there is only one other use of channel.canModify in ExtensionDNR.sys.mjs. For consistency and to avoid redundancy, I recommend to drop ChannelWrapper::IsSystemLoad() and replace its only caller in ChannelWrapper::matches with a call to ChannelWrapper::CanModify (along with setting the third parameter of CanAccessURI, aka aCheckRestricted, to false). This will result in exactly the same behavior as before. In theory, the result would be even faster since the uncommon case of the URL being unrestricted is checked after the more common channel URL matching logic.

See the bug for an explanation on why these checks are redundant.
In short, ChannelWrapper::Matches already covers the checks.