we always want necko consumers (uriloader for example) to receive OnStarts.

PDT would like more information about why this is a beta2 stopper

This is the whole issue where either we send the OnStartRequest event after the window has gone away (and potentially crash), or we don't and don't report any activity to the user if something fails to load.

this is part of some fun dependency chain.

Spoke with warren, can affect many users. Putting on [nsbeta2+][6/01] radar. This work must be done by 06/01 or we may pull this for PR2

Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] for fix deadline.

How about this patch? (Passing to mscott to review): Index: nsAsyncStreamListener.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp,v retrieving revision 1.31 diff -c -r1.31 nsAsyncStreamListener.cpp *** nsAsyncStreamListener.cpp 2000/04/05 06:45:53 1.31 --- nsAsyncStreamListener.cpp 2000/06/06 18:50:03 *************** *** 208,219 **** nsresult rv = mChannel->GetStatus(&status); NS_ASSERTION(NS_SUCCEEDED(rv), "GetStatus failed"); ! if (NS_SUCCEEDED(rv) && NS_SUCCEEDED(status)) { ! rv = receiver->OnStartRequest(mChannel, mContext); } ! else { ! NS_WARNING("not calling OnStartRequest"); ! } return rv; } --- 208,217 ---- nsresult rv = mChannel->GetStatus(&status); NS_ASSERTION(NS_SUCCEEDED(rv), "GetStatus failed"); ! if (!(NS_SUCCEEDED(rv) && NS_SUCCEEDED(status))) { ! NS_WARNING("calling OnStartRequest even though channel has a failed status"); } ! rv = receiver->OnStartRequest(mChannel, mContext); return rv; }

I checked in some changes to the uriloader (not propogating cancels to the dochsell (which could have been deleted already) that made it possible to check in this patch. I checked this patch in.

verified: WinNT 2000071008