Back to index
|void||registerContentListener (in nsIURIContentListener aContentListener)|
|As applications such as messenger and the browser are instantiated, they register content listener's with the uri dispatcher corresponding to content windows within that application. |
|void||unRegisterContentListener (in nsIURIContentListener aContentListener)|
|void||openURI (in nsIChannel aChannel, in boolean aIsContentPreferred, in nsIInterfaceRequestor aWindowContext)|
|OpenURI requires the following parameters.... |
|void||stop (in nsISupports aLoadCookie)|
|Stops an in progress load. |
|nsCOMArray< nsIWeakReference >||m_listeners|
|we shouldn't need to have an owning ref count on registered content listeners because they are supposed to unregister themselves when they go away. |
|void nsIURILoader::openURI||(||in nsIChannel||aChannel,|
OpenURI requires the following parameters....
|aChannel||The channel that should be opened. This must not be asyncOpen'd yet! If a loadgroup is set on the channel, it will get replaced with a different one.|
|aIsContentPreferred||Should the content be displayed in a container that prefers the content-type, or will any container do.|
|aWindowContext||If you are running the url from a doc shell or a web shell, this is your window context. If you have a content listener you want to give first crack to, the uri loader needs to be able to get it from the window context. We will also be using the window context to get at the progress event sink interface. Must not be null!|
As applications such as messenger and the browser are instantiated, they register content listener's with the uri dispatcher corresponding to content windows within that application.
Note to self: we may want to optimize things a bit more by requiring the content types the registered content listener cares about.
|aContentListener||The listener to register. This listener must implement nsISupportsWeakReference.|
|void nsIURILoader::unRegisterContentListener||(||in nsIURIContentListener||aContentListener||)||