|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
59 bytes, text/x-review-board-request
|Details | Review|
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
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
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.
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 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
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/8c4b779d8efa Key openRequests / openResponses on channel;r=Honza