[nsbeta2+] [6/1]

I'm trying to remember the back ground for this bug. If my memory is correct, when the uri loader receives a on start request, we want to check and see if we were canceled. If we were, we won't propogate the OnStartRequest.... OnDataAvailable calls would remain untouched....

the idea was that we wanted to ensure that OnStart's and OnStops were indeed propagated to consumers. I don't recall the context of this particular bug though.

As I recall the basic idea was that necko would always fire OnStart/OnStop in pairs (even in case of errors) - therefor URILoader needs to get changed to not assume that if OnStart would mark a beginning of Data. There could be immediate OnStop after OnStart. Also I'm not sure that merely checking for Cancel will suffice.

Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

Updating from [6/1] to [6/15]

Since this probably won't make nsbeta2, nom. nsbeta3 & rtm, *strongly* recc. nsbeta3 hard-stop. This is blocking bug 35506, "file transport needs to fire OnStart in failure case," which is blocking bug 24778, "image-button doesn't show alternative text value," which I've also nominated as nsbeta3.

Cleaning up status whiteboard by marking beta2 minus (6/15 has passed)

M16 has been out for a while now, these bugs target milestones need to be updated.

Both the bugs ekrock marked as dependent on this bug have already been fixed. There's a small piece I still have to do with the cancel propogation but this doesn't manifest itself in any user visible ways. marking to future.

Adding ekrock to CC list. rtm- based on comments in bug and current future status.

From Comment #10: "There's a small piece I still have to do with the cancel propogation but this doesn't manifest itself in any user visible ways." Is this done yet?