In order to override content handling someone implements
nsIURIContentListener, and registers their implementation w/ the
nsIURILoader service. nsIURIContentListener::OnStartURILoad() is
consulted for every load that is initated by the uriLoader, and returns
true (continue the load) or false (drop everything and stop loading. at
the time it's checked, *no* necko activity has occured, so there are no
OnStart/OnStop that would be fired). The odd thing is that the
nsIURIContentListener consulted in nsIURILoader::OpenURI() is the caller
(or someone the caller has access to) of OpenURI itself (rather than the
nsIURIContentListener that registered w/ the URILoader service). That
begs the question, why even bother w/ an OnStartURILoad() call if the
caller can just not call OpenURI() to begin with. Here's an example.
...
uriLoader->OpenURI(someURL, ..., someURIContentListener);
...
nsURILoader::OpenURI() boils down to...
nsURILoader::OpenURI(..., aContentListener) {
...
nsCOMPtr<nsIURIContentListener> listener(do_GetInterface(aContentListener));
PRBool continue = PR_TRUE;
listener->OnStartURIOpen(... &continue);
if (!continue) return NS_OK;
...
}
Am I missing something here, or is OnStartURIOpen() a moot point?
The callers of nsIURILoader::OpenURI() are imageLib, and the docShell,
so not even all URI loads pass through the URILoader. If we want to
provide true, global URI load blocking capability, should we register
some nsIURILoadListener's w/ nsIIOService, and consult them when
creating a channel? That would provide *complete* coverage at least.
Jud
