To reproduce this error you can just (100% repeatable):

• open browser and open browser console (Ctrl+Shift+J)
• now just run in console BrowserUtils.restartApplication();

Above always generate 5 same errors:
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface] network-response-listener.js:84.

This error seems to be 100% reproducible on any build and reproduces a lot on today's build.

I can confirm, I see the error a lot more today.

The error happens when getInterface is called for nsILoadContext and nsIParentChannel.

Matt, do you have any tips what could be wrong here?
Or is there anyone else I could ask?

Thanks,
Honza

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?

It sounds to me like we should update the nsIChannel implementations whose GetInterface method returns NS_ERROR_FAILURE at all to return NS_ERROR_NO_INTERFACE instead. The websocket case looks like https://searchfox.org/mozilla-central/rev/202a285024f174c2d2bf2152d9cba90a03723eab/netwerk/protocol/websocket/WebSocketChannel.cpp#3035 to me . In https://searchfox.org/mozilla-central/source/netwerk/protocol/websocket/WebSocketChannelParent.cpp#274-289 , getting the auth prompt could return something else, but given comment #11 that seems unlikely to be what's at issue here. Otherwise it'll just return whatever QueryInterface returns, which should be well-behaved, too.

It sounds like this got more frequent recently, do we know why that is?

Fixing GetInterface implementations to return NS_ERROR_NO_INTERFACE sounds good to me!

(In reply to Matt Woodrow (:mattwoodrow) from comment #14)

Fixing GetInterface implementations to return NS_ERROR_NO_INTERFACE sounds good to me!

OK, great. I am moving this report to Networking component then.
Thanks!
Honza

So, I've looked at all the C++ implementations of GetInterface in netwerk/
These are the ones that sometimes return a different error code.
We need to make sure they always return NS_OK or NS_ERROR_NO_INTERFACE

https://searchfox.org/mozilla-central/rev/4d9cd186767978a99dafe77eb536a9525980e118/netwerk/base/nsPACMan.cpp#853-854

https://searchfox.org/mozilla-central/rev/4d9cd186767978a99dafe77eb536a9525980e118/netwerk/protocol/ftp/FTPChannelParent.cpp#553

https://searchfox.org/mozilla-central/rev/4d9cd186767978a99dafe77eb536a9525980e118/netwerk/protocol/http/HttpChannelParent.cpp#316,321,328

https://searchfox.org/mozilla-central/source/netwerk/protocol/http/ParentChannelListener.cpp#169,176,182,192

https://searchfox.org/mozilla-central/rev/4d9cd186767978a99dafe77eb536a9525980e118/netwerk/protocol/websocket/WebSocketChannel.cpp#3042

https://searchfox.org/mozilla-central/rev/4d9cd186767978a99dafe77eb536a9525980e118/netwerk/protocol/websocket/WebSocketChannelParent.cpp#278

https://hg.mozilla.org/mozilla-central/rev/4aac07396ecd

Successfully reproduced the issue on Firefox Nightly (2019-10-04) under macOS 10.15.4 following the steps from Comment 9.

The errors are not thrown anymore into the console on Firefox 76.0b8 and latest Nightly 77.0a1 (2020-04-23). Tests were performed on Windows 7 (x64), Ubuntu 18.04 (x64) and macOS 10.15.4.