Closed
Bug 1363871
Opened 7 years ago
Closed 7 years ago
Errors in output: Handler function threw an exception: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIHttpChannel.channelId]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"
Categories
(DevTools :: Console, defect)
DevTools
Console
Tracking
(firefox55 fixed)
RESOLVED
FIXED
Firefox 55
Tracking | Status | |
---|---|---|
firefox55 | --- | fixed |
People
(Reporter: bgrins, Assigned: bgrins)
References
Details
Attachments
(1 file)
This started after Bug 1361140:
Handler function threw an exception: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIHttpChannel.channelId]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/webconsole/network-monitor.js :: _findActivityObject :: line 1173" data: no]
Stack: _findActivityObject@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/webconsole/network-monitor.js:1173:5
NetworkMonitor.prototype.observeActivity<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/webconsole/network-monitor.js:1019:24
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
Line: 1173, column: 0
Assignee | ||
Comment 1•7 years ago
|
||
Here's what I've figured out so far. This seems to happen with various activityType and activitySubtype values. These are passed into observeActivity in https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIHttpActivityObserver.
When loading http://example.com the following values in observeActivity result in an error when accessing channelId:
1 2152398851
1 2152398859
1 2152398855
1 2152398852
1 = ACTIVITY_TYPE_SOCKET_TRANSPORT
2152398851 = STATUS_RESOLVING
2152398859 = STATUS_RESOLVED
2152398855 = STATUS_CONNECTING_TO
2152398852 = STATUS_CONNECTED_TO
Assignee | ||
Comment 2•7 years ago
|
||
The simplest thing that will return the behavior to as it was pre bug 1361140 is to key the maps on channel instance and not channelId. This would leave open the question as to why we are getting null channels in calls to observeActivity.
I found another consumer that does a check `if (channel instanceof Ci.nsIPropertyBag2)` before accessing things on channels received from observeActivity: https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/addons/WebRequest.jsm#42-53. From some quick tests it does seem to correspond to seeing the error when accessing channelId.
Assignee | ||
Comment 3•7 years ago
|
||
Update: these do indeed seem to be nsINullChannel, which we don't need to track. We could either check if `channel instanceof Ci.nsINullChannel` and return early, or go ahead and key on channel.
I'm leaning towards keying on channel since it's analogous to the original code, and the Map values already reference the channel object, so there's not less chance of leaking by using the channelId.
Comment hidden (mozreview-request) |
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Comment 5•7 years ago
|
||
mozreview-review |
Comment on attachment 8866550 [details]
Bug 1363871 - Key openRequests / openResponses on channel;
https://reviewboard.mozilla.org/r/138146/#review141448
> 'm leaning towards keying on channel since it's analogous to the original code,
Agreed
Honza
Attachment #8866550 -
Flags: review?(odvarko) → review+
Pushed by bgrinstead@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8c4b779d8efa
Key openRequests / openResponses on channel;r=Honza
Comment 7•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox55:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•