306729 - Replace nsCachedChromeChannel with nsIInputStreamChannel (or something sane)

Status: RESOLVED FIXED

(Core :: Networking, defect, P5)

Description

[Darin Fisher]

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.

Comment 1

[Benjamin Smedberg]

It is not all that uncommon to get assertions about cachedchromechannel not
supporting "open".

Comment 2

[Darin Fisher]

really?  do you recall anyway to repro that assertion?

Comment 3

[Benjamin Smedberg]

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".

Comment 4

[Darin Fisher]

-> defaults

Comment 5

[:Cykesiopka]

It looks like Bug 206691 removed nsCachedChromeChannel and replaced it with something else. Please reopen if I'm wrong!