Closed
Bug 436836
Opened 17 years ago
Closed 17 years ago
nsIWebProgressListener gets a nsIRequest that doesn't QI to a nsIHttpChannel for for http requests
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: themystic.ca, Unassigned)
References
()
Details
Attachments
(1 file)
2.67 KB,
application/javascript
|
Details |
Attached progress listener sometimes gets a request that's an nsIRequest but not nsIHttpChannel. This is reproducible on most bugzilla searches.
Progress listener is regestered like this:
gBrowser.selectedBrowser.addProgressListener(this.progressListener, Components.interfaces.nsIWebProgress.NOTIFY_STATE_ALL);
where this.progressListener is the attached implementation of nsIWebProgressListener.
Expected results, progress listener should get an nsIRequest that implements nsIHttpChannel for all http requests.
Actual results: does not get an nsIHttpChannel for this (example) bugzilla url. Reproducible for many other searches too.
Comment 1•17 years ago
|
||
What request are you getting that you expect to implement nsIHttpChannel? E.g. what's request.name for that.
It's expected that some requests do not implement nsIHttpChannel. Especially, image loads don't (they implement imgIRequest though). There are also some pseudo-requests, but they have special request names (about:document-onload-blocker or something like that)
marking invalid for now, reopen if you're seeing this for a case not mentioned above.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•