Implementors of this interface should handle all the mechanics of actually loading an image -- getting the URI, checking with content policies and the security manager to see whether loading the URI is allowed, performing the load, firing any DOM events as needed.
An implementation of this interface may support the concepts of a "current" image and a "pending" image. If it does, a request to change the currently loaded image will start a "pending" request which will become current only when the image is loaded. It is the responsibility of observers to check which request they are getting notifications for.
Observers added in mid-load will not get any notifications they missed. We should NOT freeze this interface without considering this issue. (It could be that the image status on imgIRequest is sufficient, when combined with the imageBlockingStatus information.)
Public Member Functions
|void||addObserver (in imgIDecoderObserver aObserver)|
|void||forceImageState (in boolean aForce, in long aState)|
|imgIRequest||getRequest (in long aRequestType)|
|long||getRequestType (in imgIRequest aRequest)|
|nsIStreamListener||loadImageWithChannel (in nsIChannel aChannel)|
|void||removeObserver (in imgIDecoderObserver aObserver)|
|const long||CURRENT_REQUEST = 0|
|readonly attribute nsIURI||currentURI|
|readonly attribute short||imageBlockingStatus|
|const long||PENDING_REQUEST = 1|
|const long||UNKNOWN_REQUEST = -1|