From 26a029d407be480d791972afb5975cf62c9360a6 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Fri, 19 Apr 2024 02:47:55 +0200 Subject: Adding upstream version 124.0.1. Signed-off-by: Daniel Baumann --- uriloader/docs/index.rst | 10 ++++++++++ uriloader/docs/uriloader.rst | 46 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+) create mode 100644 uriloader/docs/index.rst create mode 100644 uriloader/docs/uriloader.rst (limited to 'uriloader/docs') diff --git a/uriloader/docs/index.rst b/uriloader/docs/index.rst new file mode 100644 index 0000000000..4943040b84 --- /dev/null +++ b/uriloader/docs/index.rst @@ -0,0 +1,10 @@ +File Handling +============= + +This covers how files requested for display are loaded. + +.. toctree:: + :maxdepth: 2 + + uriloader + exthandler/index diff --git a/uriloader/docs/uriloader.rst b/uriloader/docs/uriloader.rst new file mode 100644 index 0000000000..e0763233e5 --- /dev/null +++ b/uriloader/docs/uriloader.rst @@ -0,0 +1,46 @@ +.. _uri_loader_service: + +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 ```` 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 :ref:`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 `_. -- cgit v1.2.3