The browser would loop in nsUnknownDecoder and crash when OnStartRequest is fired on error condition. To reproduce go access non-existent host.

ruslan, I am unable to reproduce this. I'm visiting a bogus host but can't reproduce it. I don't understand how the unknown decoder would even be envoked in this case.

Oops. Yes. Because my change is commented out. Go to nsHTTPResponseListener and uncomment lines at the end in nsHTTPFinalListener.

Adding crash keyword.

[nsbeta2-] since the problem is not currently compiled into the product

Hold on. It blocks 25045,35508 .....

I see something like this now except it is from an OnStopRequest. Is this a different bug? Or is it this bug (even though the above seems to claim that this is not currently a problem)? I've seen this a few times. In the case I have a stack for it was when I clicked on a name in tinerbox. In that stack I've already 'ignored' a few of the asserts. It looked like it was going to keep asserting over and over again. I assume this would quickly blow the stack in a non-debug build. Have others been seeing this? I'll attach a stack

I'm seeing this stack blow-out too... For me it is when I access a https:// URL. I believe my PSM is not installed correctly. The cause of the recursion is the failure of nsIChannel::SetContentType() in nsUnknownDecoder::FireListenerNotifications(). see: http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#342 Since the content-type cannot be changed, when the URILoader's OnStartRequest() is called, it will create another UnknownDecode because the channel's content type is *still* application/x-unknown-content... I've attached a patch to bug #71498 which fixes this problem.

I'll take this one because it's related to bug #71498 :-)

I've checked in the patch attached to bug #71498. So this sould be fixed.

VERIFIED on branch 2001060713 linux build. Leaving as resolved until the other platforms are checked.