URI Loader Service

As its name might suggest the URI loader service is responsible for loading URIs but it is also responsible for deciding how to handle that content, whether to display it as part of a DOM window or hand it off to something else.

It is generally used when loading content for display to the user, normally from nsDocShell for display as a webpage or nsObjectLoadingContent for display inside a webpage’s <object> tag. The normal entrypoint is through nsIURILoader::OpenURI.

The URI loader starts the load and registers an nsDocumentOpenInfo as a stream listener for the content. Once headers have been received DispatchContent then decides what to do with the content as it may need to be handled by something other than the caller. It uses a few criteria to decide this including:

  • Content-Type header.

  • Content-Disposition header.

  • Load flags.

Part of this handling may include running the content through a registered stream converter to convert the content type from one to another. This is done through the stream converter service. When this happens a new nsDocumentOpenInfo is created to handle the new content in the same way as the current content.

The rough flow goes as follows (though note that this can vary depending on the flags passed to the loader service):

  1. The caller may provide an nsIURIContentListener which can offer to handle the content type or a content type that we can convert the original type to). If so the load is passed off to the listener.

  2. Global instances of nsIURIContentListener can be registered with the URI loader service so these are consulted in the same way.

  3. Global instances of nsIURIContentListener can be registered in the category manager so these are consulted in the same way.

  4. Global instances of nsIContentHandler can be registered. If one agrees to handle the content then the load is handed over to it.

  5. We attempt to convert the content to a different type.

  6. The load is handed over to the External Helper App Service.

For the most part the process ends at step 1 because nsDocShell passes a nsDSURIContentListener for the nsIURIContentListener consulted first and it accepts most of the web content types.