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
These macros will produce better outputs when they fail than these existing
patterns using `ENSURE_TRUE(NS_SUCCEEDED(...))` or similar, so this is a bulk
rewrite of existing tests to use them.
It should also help with discoverability when people base their tests off of
other existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D157214
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.
Depends on D147568
Differential Revision: https://phabricator.services.mozilla.com/D147481
The remaining methods in ns[T]StringObsolete are all find+replace methods for
nsTSubstring. These were migrated in a similar way to the find methods, and
partially updated to avoid using methods from nsStringObsolete.cpp.
This change removes the ns[T]StringObsolete.cpp files completely, as they are
no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D148301
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
This patch adds a new Content Blocking Eveent flag and modifies the
current email tracking event flag. This would allow us to log the
loading of email tracker in two levels. The level 1 email tracker
contains the base list of the email trackers, The level 2 email tracker
contains both base and content email trackers.
Differential Revision: https://phabricator.services.mozilla.com/D152679
The existing code doesn't use the sanitized extension part of the filename, when it replaces the filename when it is too long but instead used a version passed to SanitizeFileName. This newer version always gets the extension from the filename after it has been validated.
Some tests have slightly different results, because the file is now cropped slightly differently when the character count and byte count of long filenames don't match, resulting in some filenames being cropped a few extra characters more than needed.
Differential Revision: https://phabricator.services.mozilla.com/D151826
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 😅
Differential Revision: https://phabricator.services.mozilla.com/D145312
The remaining methods in ns[T]StringObsolete are all find+replace methods for
nsTSubstring. These were migrated in a similar way to the find methods, and
partially updated to avoid using methods from nsStringObsolete.cpp.
This change removes the ns[T]StringObsolete.cpp files completely, as they are
no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D148301
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 😅
Differential Revision: https://phabricator.services.mozilla.com/D145312
To do this we look at the extension on the content disposition filename, if present, or the extension
of the url, and, if it is .pdf, we assume that the file will be a pdf.
Differential Revision: https://phabricator.services.mozilla.com/D147409
This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 😅
Differential Revision: https://phabricator.services.mozilla.com/D145312
In pdf.js, files are saved thanks to a blob but the original URL is lost.
Consequently, the download panel doesn't contain any information about the
origins of a saved pdf.
The saveURL, internalSave and nsITransfer.init functions has now a parameter for this originalURL.
Differential Revision: https://phabricator.services.mozilla.com/D147651
The component that handles MIME type information will consult whatever
the OS uses as a registry of file types / applications; in the past
this caused problems for sandboxing on macOS and then Windows, so IPC was
used to remote those queries to the parent process.
We've also been having similar problems on Linux, and none of the
infrastructure here seems to be OS-specific; therefore I've removed the
`#ifdef` so that we always use IPC.
Differential Revision: https://phabricator.services.mozilla.com/D145823
This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
This test involves clicking on a link to a .bin file. In the Mac test environment, this is given the macbinary content type. This test assumes that it will be octet-stream (another valid content type for the bin extension) and sets the alwaysAskBeforeHandling flag for that, so the dialog never shows up. However, another subtest needs octet-stream to prompt as well, so set the always ask for both.
Differential Revision: https://phabricator.services.mozilla.com/D145547
This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 😅
Differential Revision: https://phabricator.services.mozilla.com/D145312
This test involves clicking on a link to a .bin file. In the Mac test environment, this is given the macbinary content type. This test assumes that it will be octet-stream (another valid content type for the bin extension) and sets the alwaysAskBeforeHandling flag for that, so the dialog never shows up. However, another subtest needs octet-stream to prompt as well, so set the always ask for both.
Differential Revision: https://phabricator.services.mozilla.com/D145547
With MOZ_FORMAT_PRINTF annotations, the compiler expects a wchar_t*, and
it won't automatically consider char16ptr_t to be compatible with that.
While handling strings, there's one case of formatting that doesn't need
to use %S at all.
Differential Revision: https://phabricator.services.mozilla.com/D144919
The patch appears to have caused an increase in timeouts, but based on a
quick scan of the log, it appears it's due to the test running right
against the time limit, rather than due to the test deadlocking or
similar.
Differential Revision: https://phabricator.services.mozilla.com/D145235
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
Gijs Kruitbosch
Nika Layzell
Butkovits Atila
Sandor Molnar
Meg Viar
Barret Rennie
Calixte
Stanca Serban
Dave Townsend
Mark Banner
Valentin Gosu
Dan Robertson
Neil Deakin
alwu
Shane Caraveo
Cristian Tuns
Daniel Holbert
Mike Conley
Eemeli Aro
Shane Hughes
Andrew McCreight
Mathew Hodson
Dana Keeler
Marco Bonardo
Norisz Fay
Kershaw Chang
Masatoshi Kimura
Paul Zuehlcke
Andi-Bogdan Postelnicu
Christian Holler
Tim Huang
Tooru Fujisawa
Emilio Cobos Álvarez
criss
Andreea Pavel
Kris Maglione
Tom Schuster
Dimi
Manuel Bucher
Cosmin Sabou
Jed Davis
Kagami Sascha Rosylight
lyavor
Csoregi Natalia
Noemi Erli
Jens Stutte
Mike Hommey
Sarah Clements
Iulian Moraru