Bugzilla

The throwing code has been added in bug 1309523.
Comment mentions that this is specific to non-e10s codepath.
I'm having a hard time to understand this comment:
```
  // Note that this is really only needed for the non-e10s case.
  // See bug 1309523.
  const channel = this.httpActivity.channel;
  this._wrappedNotificationCallbacks = channel.notificationCallbacks;
  channel.notificationCallbacks = this;
```
We should not have much or any non-e10s codepath nowadays?
If I comment these lines, devtools/client/netmonitor/test/browser_net_content-type.js fails, so it seems still relevant.
Could it be that non-e10s means "codepath in the parent process"?

As comment 4,5,6 stated, this relates to WebSocket as the throwing channel is about `wss://push.services.mozilla.com/` request.
This code should only run in the parent process, so I imagine we are calling this method:
https://searchfox.org/mozilla-central/source/netwerk/protocol/websocket/WebSocketChannelParent.cpp#274-289
Which seems to implement only two interfaces:

The throwing code has been added in bug 1309523.
Comment mentions that this is specific to non-e10s codepath.
I'm having a hard time to understand this comment:
```
  // Note that this is really only needed for the non-e10s case.
  // See bug 1309523.
  const channel = this.httpActivity.channel;
  this._wrappedNotificationCallbacks = channel.notificationCallbacks;
  channel.notificationCallbacks = this;
```
We should not have much or any non-e10s codepath nowadays?
If I comment these lines, devtools/client/netmonitor/test/browser_net_content-type.js fails, so it seems still relevant.
Could it be that non-e10s means "codepath in the parent process"?
This one test assert netmonitor behavior against a content page, but all the throwing cases are about requests which might be done from the parent process.

As comment 4,5,6 stated, this relates to WebSocket as the throwing channel is about `wss://push.services.mozilla.com/` requests.
This code should only run in the parent process, so I imagine we are calling this method:
https://searchfox.org/mozilla-central/source/netwerk/protocol/websocket/WebSocketChannelParent.cpp#274-289

But this also throws for `https://incoming.telemetry.mozilla.org/submit/telemetry/2be115ed-f0a4-4006-a873-daee6642aee3/main/Firefox/76.0a1/default/20200319010007?v=4`, where `_wrappedNotificationCallbacks` will be an XMLHttpRequest object.

As Honza just said, both cases fail to get nsIParentChannel and nsILoadContext interfaces.

A patch like this one prevents having error reports:
```
diff --git a/devtools/server/actors/network-monitor/network-response-listener.js b/devtools/server/actors/network-monitor/network-response-listener.js
index 1128065a0f25..e9a6764acbcd 100644
--- a/devtools/server/actors/network-monitor/network-response-listener.js
+++ b/devtools/server/actors/network-monitor/network-response-listener.js
@@ -81,7 +81,11 @@ NetworkResponseListener.prototype = {
       return this;
     }
     if (this._wrappedNotificationCallbacks) {
-      return this._wrappedNotificationCallbacks.getInterface(iid);
+      try {
+        return this._wrappedNotificationCallbacks.getInterface(iid);
+      } catch(e) {
+        throw Cr.NS_ERROR_NO_INTERFACE;
+      }
     }
     throw Cr.NS_ERROR_NO_INTERFACE;
   },
```
Is that acceptable?
Should WebSocket and XMLHttpRequest `GetInterface` methods  throw `NS_ERROR_NO_INTERFACE` instead of `NS_ERROR_FAILURE`?
Could it actually be the underlying issue here?