Closed Bug 1179250 Opened 5 years ago Closed 3 days ago

JavaScript error: resource://devtools/server/actors/network-monitor/network-response-listener.js, line 84: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface]

Categories

(Core :: Networking, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla76
Tracking Status
firefox42 --- wontfix
firefox76 --- fixed

People

(Reporter: Gijs, Assigned: mbansal, Mentored)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

This error appears a few seconds after starting and opening the browser console. I'm not 100% what triggers it but I've been seeing it a lot and it's annoying me. :-)

The error'ing code here is:

      return this._wrappedNotificationCallbacks.getInterface(iid);

in 

  getInterface(iid) {

for the NetworkResponseListener.

I'm unsure who works on the network monitor these days. Patrick, can you redirect to the right person?
Flags: needinfo?(pbrosset)
I'll take a look.  I originally added this line a while ago.
Flags: needinfo?(pbrosset)
These failures are associated with requests to https://push1.push.hello.firefox.com/ that upgrade to WebSockets.

The NetworkResponseListener installs its own notificationCallbacks on the channel:

1. For HTTP channels, this calls the setter[1]
2. As part of the setter, CanSetCallbacks[2] is called
3. CanSetCallbacks tries to get the nsILoadContext interface
4. NetworkResponseListener does not implement nsILoadContext, so it passes the request to the original callbacks
5. For these particular channels, getting nsILoadContext from the original callbacks returns NS_ERROR_FAILURE

So far, I am not yet sure why these channels fail in this way.

[1]: https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/HttpBaseChannel.cpp#336
[2]: https://dxr.mozilla.org/mozilla-central/source/netwerk/base/PrivateBrowsingChannel.h#65
Could we ask someone from the hello team to help? Or maybe just silence the errors?
Flags: needinfo?(jryans)
I don't believe it's specific to Hello, but more likely something about WebSockets.

It seems like :baku has done a lot of work on WebSockets.  :baku, do you know why some WebSockets would fail when asking for the nsILoadContext interface?  I wasn't sure where that code actually lives...
Flags: needinfo?(jryans) → needinfo?(amarchesini)
Debugging this code, I see that:

1. nsILoadContext is exposed only in the WebSocketChannel parent. No child process.
2. and only the channel has been created with a LoadContext. As FTPChannel and HTTPChannel do.

can you create a test case? How easy is to reproduce this issue?
Flags: needinfo?(amarchesini) → needinfo?(jryans)
(In reply to Andrea Marchesini (:baku) from comment #5)
> Debugging this code, I see that:
> 
> 1. nsILoadContext is exposed only in the WebSocketChannel parent. No child
> process.
> 2. and only the channel has been created with a LoadContext. As FTPChannel
> and HTTPChannel do.
> 
> can you create a test case? How easy is to reproduce this issue?

Sorry for the delay in replying.  I've been a bit swamped lately.

AFAIK, the network monitor accesses request data from the parent process, so #1 above sounds okay.

It's easy to reproduce for me:

1. Start Firefox
2. Quickly open the Browser Console[1] (within a few seconds) so it's open before startup WebSocket requests
3. Firefox makes a WebSocket request to https://push.services.mozilla.com/ (in Nightly 43)
4. One or more of these errors are logged to the Browser Console

I have not yet had time to construct a reduced test case.  I'll keep this tab open and attempt to do so when I have more time.

[1]: https://developer.mozilla.org/en-US/docs/Tools/Browser_Console
Flags: needinfo?(jryans)
Product: Firefox → DevTools
Hello guys, 

I also encountered a similar problem while testing on the latest 64.0b13.

STR:
1. Launch FF.
2. Launch the Browser Console.
3. Go to Facebook and launch with valid credentials.
4. Enter Vegas Downtown Slots&Words.
5. Perform several actions inside the game(visit different subsections, enter action phase)
6. Press either the Facebook or Home button to return to account wall of activity.

ER:
- The browser console should not return any errors.

AR:
- The browser console returns NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface]on the path resource://devtools/server/actors/network-monitor/network-response-listener.js:73

Other notes:

- Encountered this error on Windows 10x64, macOS 10.11.6.
- Encountered this error both on x86 and x64 beta 64.0b13 builds
- Repro rate is only about 30% (3 out of 10 attempts)
- When attempting to reproduce the issue, out of the 7 attempts in which the issue was not reproduced, the "InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable" error is received instead.
- Screenshot of the error: https://drive.google.com/file/d/1lolOZDaLZcKO1MzCbxcZ04AILG9_iXrr/view?usp=sharing

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.

See Also: → 1611081
Summary: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface] (network-monitor.js:94) → JavaScript error: resource://devtools/server/actors/network-monitor/network-response-listener.js, line 84: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface]

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

Flags: needinfo?(matt.woodrow)

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?

Depends on: 1309523

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!

Flags: needinfo?(matt.woodrow)

(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

Component: Netmonitor → Networking
Product: DevTools → Core
Assignee: nobody → mbansal
Status: NEW → ASSIGNED
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/4aac07396ecd
Make implementation of GetInterface return NS_ERROR_NO_INTERFACE on error.r=valentin
Status: ASSIGNED → RESOLVED
Closed: 3 days ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
You need to log in before you can comment on or make changes to this bug.