It looks like nsCachedChromeChannel could be replaced with a nsInputStreamChannel instance that loads data from an empty stream. Besides reducing code this would also make the nsCachedChromeChannel implement nsIChannel properly (including support for nsIChannel.open, nsIRequest.suspend, and nsIRequest.resume). I think nsCachedChromeChannel may also not implement cancel properly since it appears to never call OnStartRequest and OnStopRequest if canceled! I don't know of any reported bugs that would be fixed by making this change, so I'm setting severity to minor.
It is not all that uncommon to get assertions about cachedchromechannel not supporting "open".
really? do you recall anyway to repro that assertion?
It's almost always paired with the fastload "URI mapped to two different specs" assertion, I never tracked it far enough to figure which was the chicken and which the egg. It was easy to reproduce while I was testing dbaron's live skin-switching stuff, I haven't seen it during "ordinary browsing".
Assignee: darin.moz → nobody
QA Contact: benc → networking
It looks like Bug 206691 removed nsCachedChromeChannel and replaced it with something else. Please reopen if I'm wrong!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.