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)

1.8 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: themystic.ca, Unassigned)

References

()

Details

Attachments

(1 file)

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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: