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)
Tracking
()
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?
I'll take a look. I originally added this line a while ago.
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
|
Reporter | |
Comment 3•9 years ago
|
||
Could we ask someone from the hello team to help? Or maybe just silence the errors?
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...
|
||
Comment 5•9 years ago
|
||
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?
(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
|
||
Updated•8 years ago
|
|
||
Updated•6 years ago
|
|
||
Comment 7•6 years ago
|
||
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
| Comment hidden (Intermittent Failures Robot) |
|
||
Comment 9•5 years ago
|
||
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.
|
||
Updated•4 years ago
|
|
|
||
Comment 10•4 years ago
|
||
This error seems to be 100% reproducible on any build and reproduces a lot on today's build.
|
|
||
Comment 11•4 years ago
|
||
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
|
|
||
Comment 12•4 years ago
•
|
||
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?
|
|
Reporter | |
Comment 13•4 years ago
•
|
||
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.
|
||
Comment 14•4 years ago
|
||
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!
|
|
||
Comment 15•4 years ago
|
||
(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
|
||
Comment 16•4 years ago
|
||
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
|
Assignee | |
Comment 17•4 years ago
|
||
|
||
Updated•4 years ago
|
|
||
Comment 18•4 years ago
|
||
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
|
||
Comment 19•4 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Comment 20•4 years ago
|
||
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.
Description
•