Necko channels have a contract (see nsIChannel::asyncOpen) where they release their ref to the listener after the last callback is completed. But as I'm finding in bug 748766 comment 10, we've got channels hanging onto some listeners (in this case, WebsocketChannels) until they're destroyed. I'm doing a quick audit to see if there are other places in necko where we don't release after OnStop--another patch to follow (or maybe separate bug).

> Necko channels have a contract (see nsIChannel::asyncOpen) where they > release their ref to the listener after the last callback is completed. I don't have a problem believing this - indeed I do! But I don't see that clearly spelled out in nsIChannel as you indicate. Maybe we can make that explicit or am I missing it entirely?

Comment on attachment 628381 [details] [diff] [review] teach 3 necko classes to release listeners after OnStopRequest Review of attachment 628381 [details] [diff] [review]: ----------------------------------------------------------------- this is good research! ::: netwerk/base/public/nsStreamListenerWrapper.h @@ +25,5 @@ > > + // Don't use NS_FORWARD_NSIREQUESTOBSERVER(mListener->) here, because we need > + // to release mListener in OnStopRequest, and IDL-generated function doesn't. > + NS_SCRIPTABLE NS_IMETHOD OnStartRequest(nsIRequest *aRequest, > + nsISupports *aContext) "and *a* IDL-ge.." ?

Might be also related to bug 746255.

why is this r+ patch stalled?

Try run looks good: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5e742f847295

Backed out for crashes (see bug 1274279) https://hg.mozilla.org/integration/mozilla-inbound/rev/7f39530aedec

Not sure when I'll get to this again, so freeing it back to the necko backlog. If someone wants to give it a try, I recommend applying only some of the patch and see which part is breaking things.

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258