Readonly CORSModeThe CORS mode that this image was loaded with (a mozilla::CORSMode).
Readonly URIThe URI the image load was started with. Note that this might not be the actual URI for the image (e.g. if HTTP redirects happened during the load).
Readonly fileThe filename that should be used when saving the image. This is determined from the Content-Disposition, if present, or the uri of the image. This filename should be validated using nsIMIMEService::GetValidFilenameForSaving before creating the file.
Readonly finalURIThe URI of the resource we ended up loading after all redirects, etc.
Readonly hadtrue if the loading of the image required cross-origin redirects.
Readonly imagethe image container...
the image object associated with the request.
NEED DOCS
Readonly imageActual error code that generated a STATUS_ERROR imageStatus (see xpcom/base/ErrorList.h)
Readonly imageThe principal gotten from the channel the image was loaded from.
Readonly imageStatus flags of the STATUS_* variety.
The load flags of this request. Bits 0-15 are reserved.
When added to a load group, this request's load flags are merged with the load flags of the load group.
The load group of this request. While pending, the request is a member of the load group. It is the responsibility of the request to implement this policy.
Readonly mimeReadonly multipartWhether the request is multipart (ie, multipart/x-mixed-replace)
Readonly nameThe name of the request. Often this is the URI of the request.
Readonly notificationReadonly providerProvider ID for image providers created by this image.
Readonly referrerThe referrer that this image was loaded with.
Readonly statusThe error status associated with the request.
Readonly triggeringThe principal for the document that loaded this image. Used when trying to validate a CORS image load.
Optional aInstancePtr: objectA run time mechanism for interface discovery.
NS_OK if the interface is supported by the associated instance, NS_NOINTERFACE if it is not.
aInstancePtr must not be null.
[in] A requested interface IID
[out] A pointer to an interface pointer to receive the result.
Cancels the current request. This will close any open input or output streams and terminate any async requests. Users should normally pass NS_BINDING_ABORTED, although other errors may also be passed. The error passed in will become the value of the status attribute.
Implementations must not send any notifications (e.g. via nsIRequestObserver) synchronously from this function. Similarly, removal from the load group (if any) must also happen asynchronously.
Requests that use nsIStreamListener must not call onDataAvailable anymore after cancel has been called.
the reason for canceling this request.
NOTE: most nsIRequest implementations expect aStatus to be a failure code; however, some implementations may allow aStatus to be a success code such as NS_OK. In general, aStatus should be a failure code.
Cancels this request as in nsIRequest::Cancel(); further, also nulls out decoderObserver so it gets no further notifications from us.
NOTE: You should not use this in any new code; instead, use cancel(). Note that cancel() is asynchronous, which means that some time after you call it, the listener/observer will get an OnStopRequest(). This means that, if you're the observer, you can't call cancel() from your destructor.
Clone this request; the returned request will have aObserver as the observer. aObserver will be notified synchronously (before the clone() call returns) with all the notifications that have already been dispatched for this image load.
These methods encode/decode the TRR mode to/from the loadFlags. Helper methods Get/SetTRRModeImpl are provided so implementations don't need to duplicate code.
Requests with TRR_DEFAULT_MODE will use the mode indicated by the pref
Indicates whether the request is pending. nsIRequest::isPending is true when there is an outstanding asynchronous event that will make the request no longer be pending. Requests do not necessarily start out pending; in some cases, requests have to be explicitly initiated (e.g. nsIChannel implementations are only pending once asyncOpen returns successfully).
Requests can become pending multiple times during their lifetime.
TRUE if the request has yet to reach completion.
FALSE if the request has reached completion (e.g., after OnStopRequest has fired).
Suspended requests are still considered pending.
Locks an image. If the image does not exist yet, locks it once it becomes available. The lock persists for the lifetime of the imgIRequest (until unlockImage is called) even if the underlying image changes.
If you don't call unlockImage() by the time this imgIRequest goes away, it will be called for you automatically.
imgIContainer::lockImage for documentation of the underlying call.
This method triggers decoding for an image, but unlike startDecoding() it enables the caller to provide more detailed information about the decode request.
DECODE_SURFACE_AVAILABLE if is a surface that satisfies the request and it is fully decoded. DECODE_REQUESTED if we requested a decode. DECODE_REQUEST_FAILED if we failed to request a decode. This means that either there is an error in the image or we cannot allocate a surface that big.
Flags of the FLAG_* variety.
Requests a synchronous decode for the image.
imgIContainer has a startDecoding() method, but callers may want to request a decode before the container has necessarily been instantiated. Calling startDecoding() on the imgIRequest simply forwards along the request if the container already exists, or calls it once the container becomes available if it does not yet exist.
Suspends the current request. This may have the effect of closing any underlying transport (in order to free up resources), although any open streams remain logically opened and will continue delivering data when the transport is resumed.
Calling cancel() on a suspended request must not send any notifications (such as onstopRequest) until the request is resumed.
NOTE: some implementations are unable to immediately suspend, and may continue to deliver events already posted to an event queue. In general, callers should be capable of handling events even after suspending a request.
Generated using TypeDoc
imgIRequest interface
Author
Stuart Parmenter stuart@mozilla.com
Version
0.1
See
imagelib2