1363871 - 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)"

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[Brian Grinstead [:bgrins]]

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

Comment 1

[Brian Grinstead [:bgrins]]

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

Comment 2

[Brian Grinstead [:bgrins]]

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.

Comment 3

[Brian Grinstead [:bgrins]]

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 4

[Brian Grinstead [:bgrins]]

Attachment: Bug 1363871 - Key openRequests / openResponses on channel;

This prevents NS_ERROR_NOT_IMPLEMENTED on nsIHttpChannel.channelId when
it is called with an nsINullChannel.

Review commit: https://reviewboard.mozilla.org/r/138146/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/138146/

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

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

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8c4b779d8efa
Key openRequests / openResponses on channel;r=Honza

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/8c4b779d8efa