nsIRequest::IsPending not set to false uniformly

NEW
Unassigned

Status

()

Core
Networking
P5
minor
13 years ago
9 months ago

People

(Reporter: Darin Fisher, Unassigned)

Tracking

Trunk
mozilla1.9alpha1
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-would-take])

(Reporter)

Description

13 years ago
While working with bryner on one of the bfcache bugs, we found that
nsIRequest::isPending is not set to false in a uniform way.  For example, the
HTTP channel sets isPending to false before calling OnStopRequest, while other
channels set isPending to false after calling OnStopRequest.

It would be nice if all channels set IsPending to false before calling
OnStopRequest so that way downstream someone could determine if the channel is
in the process of calling OnStopRequest.  for example, in the case of a
multipart mixed response, it would have been nice if one could inspect the
IsPending state of the partChannel's baseChannel to determine if the
OnStopRequest being called is the last OnStopRequest.  bryner added
nsIMultiPartChannel::IsLastPart to get around this problem.

there may be other cases where being consistent here matters, so we should fix it.
(Reporter)

Updated

13 years ago
Target Milestone: --- → mozilla1.9alpha
(Reporter)

Comment 1

13 years ago
This bug is partially fixed for the protocol handlers covered by bug 312760.
Depends on: 312760
(Reporter)

Updated

13 years ago
Priority: -- → P2
(Reporter)

Comment 2

12 years ago
-> defaults
Assignee: darin.moz → nobody
QA Contact: benc → networking
I think we should fix this for 1.9...
Flags: blocking1.9?

Comment 4

11 years ago
biesi, are you interested in taking this?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Assignee: nobody → cbiesinger
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Assignee: cbiesinger → nobody

Comment 5

6 years ago
Honza, Michal, Patrick - do you guys know if this is still an issue?
I don't know if there's inconsistency between protocols anymore, but we're still inconsitstent *within* HTTP: see bug 748117
Whiteboard: [necko-would-take]
You need to log in before you can comment on or make changes to this bug.