author Anna Yeddi <ayeddi@mozilla.com>
Mon, 30 Jan 2023 23:53:14 +0000
changeset 651013 3479f77e7402f18d6e3638ff131c0f35386fb493
parent 517512 f0f7f4bd76d1c2abcc1dd6efb485b369d44e9782
permissions -rw-r--r--
Bug 1802621 - Move browser_datetime tests in their own subdirectory. r=mconley Moved the datepicker-related browser tests in the new subdirectory `datetime` within `toolkit/content/tests/browser/`. Besides `browser_datetime_*` tests `browser_spinner*` ones were also moved, because they share a lot of helper functions and are used for DateTimePicker widgets as well. The subdirectory includes a `header.js` with the `DateTimeTestHelper` class constructor and opther helper functions used across the DateTimePicker test files. It also splits larger test files to avoid intermittent timeouts caused by the large sets of use cases performed. `Browser.ini` includes `skip-if` cases for `browser_datetime_datepicker_*` tests that were provided initially but were not copied to the expanded browser test files in the bug 1676068 work. Differential Revision: https://phabricator.services.mozilla.com/D168140

.. _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 ``<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 <https://searchfox.org/mozilla-central/search?q=nsDocumentOpenInfo%3A%3ADispatchContent&path=>`_
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 <https://searchfox.org/mozilla-central/source/netwerk/streamconv>`_.
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 <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 <https://searchfox.org/mozilla-central/search?q=CONTENTDLF_CATEGORIES&redirect=false>`_.