Note that modules can't be specified in Link preloads with `rel=preload`,
only in `rel=modulepreload`. We currently only support `rel=preload` in
early hints. See Bug 1798319 for updates on module preloads.
Differential Revision: https://phabricator.services.mozilla.com/D161175
Note that modules can't be specified in Link preloads with `rel=preload`,
only in `rel=modulepreload`. We currently only support `rel=preload` in
early hints. See Bug 1798319 for updates on module preloads.
Differential Revision: https://phabricator.services.mozilla.com/D161175
This removes all implementations of these types. Some implementations in JS
code were also removed in the previous part, when updating tests to use
`Services.io.registerProtocolHandler`.
Code which used to access these members should go through the IOService now
instead.
Differential Revision: https://phabricator.services.mozilla.com/D162805
This removes all implementations of these types. Some implementations in JS
code were also removed in the previous part, when updating tests to use
`Services.io.registerProtocolHandler`.
Code which used to access these members should go through the IOService now
instead.
Differential Revision: https://phabricator.services.mozilla.com/D162805
The previous part introduced a new mechanism to track the triggering remote
type for a specific load in a reliable way. This adds some basic checks based
on the triggering remote type to the nsContentSecurityManager, while also
providing the potential infrastructure to expand these checks in the future.
As these checks are performed before some other content security checks (to
ensure that they are performed before InitialSecurityCheckDone() is checked),
they may reject a load which would otherwise have been rejected by a later
check. For this reason, the diagnostic assertions added in this part are only
fired if the check appears as though it would otherwise have succeeded. This
check is not fully accurate, however, so may miss some cases.
This is important, as we have some tests, such as service worker navigation
tests, which will try to load file:/// URIs in content processes, and only fail
in the later content security checks.
For now, no checks are performed for non-document loads, though that may change
in the future.
Differential Revision: https://phabricator.services.mozilla.com/D161199
This is done using slightly different mechanisms for each of LoadInfo and
nsDocShellLoadState, and will be used in the next part to validate document
loads based on the RemoteType responsible for the load.
For subresource loads, the TriggeringRemoteType is fairly straightforward - it
is the process which created the channel. We can handle this by getting the
current remote type when creating the channel, and then using the remote type
of the sending process when receiving the LoadInfo over IPC to either replace
the triggering remote type, or validate it.
For document loads, the situation is a bit more complex, as there are at least
3 (potentially-)different processes responsible for different parts of the
navigation:
1. The "Triggering Process" is the process which provided the URI to load.
This is also the process which provides the Triggering Principal. This is
the process being tracked in this patch.
2. The "Loading Process" is the process which actually creates the channel and
starts the load. This may be the same as the triggering process, or may be
a different process starting the navigation on behalf of the triggering
process. In general this is the process hosting the current docshell,
though it may be the parent process in the case of parent-initiated loads.
3. The "Final Process" is the process which receives the response and renders
the final document. This isn't known at channel creation time, and is
determined by the result principal and process isolation policy.
This change uses a serializer and special field on nsDocShellLoadState to track
the "Triggering Process" for the load, even as the load state is serialized
between processes by tracking which loads were sent into which content
processes, and matching them up when the parent process sees them again. The
information is then copied into the LoadInfo before configuring the real
channel, so it can be used for security checks.
The "Triggering Process" is overridden to be the parent process for history
loads, as history loads are often started in processes which wouldn't normally
be able to navigate to those pages. This is OK thanks to the changes in part 1
which validate history loads against the real session history when SHIP is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D161198
Just add the minimal stuff in order to be able to view a pdf in using pdf.js
(whatever the content disposition is).
There are still some things to plug (e.g. find stuff), we must change the UI
and add support for pinch-to-zoom, hence we set the pref pdfjs.disabled to true.
Differential Revision: https://phabricator.services.mozilla.com/D162122
In order to handle the content script case correctly we must expose the
contentScriptAddonPolicy to JavaScript. With that we can always see what
extension is trying to perform an action and use its name rather than internal
ID in the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D161282
Set the Content-Type to an empty string for an blob when the type was not
given. Ensure that the channel Content-Type is not overriden in the case
that it was previously set and the blob type is not valid.
Differential Revision: https://phabricator.services.mozilla.com/D147481
Currently this function uses six different booleans to decide which code to run
to trigger the load (many of which are used in just one test) and elsewhere I
need to add more cases. This changes the function to instead take a callback
function so individual tests can just pass their one-off functions. For the
few that are shared global functions are used to share those.
Differential Revision: https://phabricator.services.mozilla.com/D161588
DONTBUILD because this is just whitespace cleanup.
I found the files to fix up here using this command:
grep -r ' ' * 2>/dev/null | grep -v "other-licenses" | grep "idl:"
I replaced the tab characters with however many spaces seemed consistent with
the indentation in the surrounding code (and did some minor space-indentation
cleanup in contextual lines to preserve alignment, in a few cases).
Differential Revision: https://phabricator.services.mozilla.com/D160577
This patch modifies DownloadSpamProtection and DownloadIntegration so
that each window will track blocked spam downloads separately. (Which
shouldn't affect permissions.) When a download is blocked, the helper
app service dispatches a notification, passing the relevant browsing
context and URL to DownloadIntegration. Then it passes the window and
URL to the singleton DownloadSpamProtection. That maps all the windows
to objects that carry the spam download objects. This allows us to only
show blocked spam downloads in the downloads panel of the window from
which they were triggered.
Differential Revision: https://phabricator.services.mozilla.com/D148092
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
