To reproduce: Go to http://bugzilla.mozilla.org/query.cgi enter Mozilla0.9.2 as the target milestone then submit query. The nsParser listener's OnStopRequest is called once. It is not called for the second document. Tracing into the nsMultiMixedConv implementation the mPartChannel is null when the second call to nsMultiMixedConv::OnStopRequest is made so it does not pass the OnStopRequest over to the parser. NS_IMETHODIMP nsMultiMixedConv::OnStopRequest(nsIRequest *request, nsISupports *ctxt, nsresult aStatus) { ... if (mPartChannel) { <== this is null for some reason

This bug is blocks 76722, because with the patch enabled in bug 76722 the throbber will spin forever on Mozilla queries because the OnStopRequest for the second document is never called.

This bug also blocks ( I think ) bug 49539. I think the patch in bug 70398 should do the trick.

scott, this is the patch that harishd and I spoke to you on the phone last week about. It basically removes that Bool that prevents multiple onStopRequests from the URILoader. Can I get a SR from your? Rick, please review this for a r=? Kevin, when is this needed by? 0.9.3?

I need it for 0.9.3 so I can enable the patch in bug 76722 for 0.9.3.

I have been running with patch 39919 and it fixes the "throbber never stops spinning" issue that is blocking 76722

kevin, can you reproduce 84774?

patch, id 39919, looks good to me. r=harishd

sr=mscott

patch 39919 fixes bug 84774

fix checked in: Checking in nsURILoader.cpp; /cvsroot/mozilla/uriloader/base/nsURILoader.cpp,v <-- nsURILoader.cpp new revision: 1.79; previous revision: 1.78 done

hey doug, your patch introduces a possible re-enterent call of OnStopRequest(...) which mOnSgtopFired was preventing :-( I'm attaching a patch which handles this situation. -- rick

sr=mscott on rick's patch

I'm also talking with mscott about the ramifications of removing the early return from ProcessCanceledCase(...). Currently, we will *not* call OnStopRequest(...) if the channel ends up being canceled :-( I believe that this is *very* bad because the consumer expects to always be called!

yes, that is really bad! what can be done about it?

your patch 43077 looks okay r=dougt

So, after talking it over with mscott, we both agreed that calling ProcessCanceledCase(..) inside of OnStopRequest(...) was unnecessary/bad. Since it will still be called in OnStartRequest(...) the situation caused by bug #40116 (which the code was added for) will still be handled correctly. So, i'm attaching a new patch (if you liked the last one you'll love this one) which also removes the call to ProcessCanceledCase(...) in OnStopRequest.

-> rpotts. since I have the patch :-)

r=dougt

I've just checked the patch (40400) into the trunk... I'm just waiting to check in into the branch too.

I forgot to mention that I have verified that bug #40116 has not been re-introduced by removing the call to ProcessCanceledCase() from OnStopRequest(...). I did this by placing a breakpoint in ProcessCanceledCase() and going back and forth on http://news.bbc.co.uk/ until I hit the breakpoint... Then, I verified that we didn't crash :-) --rick

sr=mscott

a=choffman I've just landed both patches (dougt and mine) onto the branch.