Judson Valeski wrote:
> 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
What about if the user clicks on a link? In that instance, the embedder won't
have called loadURI (somewhere in webshell does it) but they may still want to
prevent the operation from proceeding.
