In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
This patch changes the default behaviour of `download()`.
- Previous file-based behaviour was moved to `downloadToDisk()` and `deleteFromDisk()`. Existing consumers were migrated to avoid behaviour change.
- `download()` has now `{useCache: true}` by default, option was dropped, and `deleteCached()` is now `deleteDownloaded()`
Differential Revision: https://phabricator.services.mozilla.com/D141980
This patch changes the default behaviour of `download()`.
- Previous file-based behaviour was moved to `downloadToDisk()` and `deleteFromDisk()`. Existing consumers were migrated to avoid behaviour change.
- `download()` has now `{useCache: true}` by default, option was dropped, and `deleteCached()` is now `deleteDownloaded()`
Differential Revision: https://phabricator.services.mozilla.com/D141980
Before this change, all XPIDL constants were declared using an anonymous
`enum` rather than using a static constant. This change makes the
generated code more consistent with what is done in languages like Rust.
Some small changes were needed due to signed/unsigned comparison
warnings which were previously silent.
Differential Revision: https://phabricator.services.mozilla.com/D143090
Before this patch, nsISiteSecurityService APIs took "flags" parameters that
differentiated private contexts from not private contexts. However, these
parameters were redundant with respect to origin attributes, which led to some
confusion for consumers of these APIs. This patch removes these parameters in
favor of using origin attributes.
Differential Revision: https://phabricator.services.mozilla.com/D142901
Given that we only support samesite lax/strict/none in our storage schema,
it's useful to introduce a default value, as required by the spec.
However, that would it hard to distinguish between none/lax when we switch
the default.
So, instead of doing that we use the peculiarities of our current schema
to our advantage: There's a "sameSite" attribute and a "rawSameSite"
attribute, where the latter is the literal value we received from the
server. With this patch, we'll interpret the "sameSite" attribute
based on the laxByDefault pref. This also has the advantage that various
front-end code (e.g., in DevTools) is always reading the "sameSite"
value of nsICookies.
Differential Revision: https://phabricator.services.mozilla.com/D137460
This patch implements that the referrer protection can be disabled by
the ETP toggle. When ETP is toggled off, it will stop the protection for
iframe and sub-resource loads. Also, it will stop the protection for a
loading to a site that has ETP disabled.
This patch also makes
CookieJarSettings::UpdateIsOnContentBlockingAllowList() be more
efficient when calling it multiple times.
Differential Revision: https://phabricator.services.mozilla.com/D142249
Given that we only support samesite lax/strict/none in our storage schema,
it's useful to introduce a default value, as required by the spec.
However, that would it hard to distinguish between none/lax when we switch
the default.
So, instead of doing that we use the peculiarities of our current schema
to our advantage: There's a "sameSite" attribute and a "rawSameSite"
attribute, where the latter is the literal value we received from the
server. With this patch, we'll interpret the "sameSite" attribute
based on the laxByDefault pref. This also has the advantage that various
front-end code (e.g., in DevTools) is always reading the "sameSite"
value of nsICookies.
Differential Revision: https://phabricator.services.mozilla.com/D137460
- nsHttpConnection now has states. Currently only proxy setup phase is added to the states.
- The states are used in nsHttpConnection::OnSocketWritable tto make the code more understandable.
- Some pieces of selfcontained code are extracted from nsHttpConnection::OnHeadersAvailable, i.e. HandleTunnelResponse and HandleWebSocketResponse
Differential Revision: https://phabricator.services.mozilla.com/D138714
- nsHttpConnection now has states. Currently only proxy setup phase is added to the states.
- The states are used in nsHttpConnection::OnSocketWritable tto make the code more understandable.
- Some pieces of selfcontained code are extracted from nsHttpConnection::OnHeadersAvailable, i.e. HandleTunnelResponse and HandleWebSocketResponse
Differential Revision: https://phabricator.services.mozilla.com/D138714
This removes a part of the erroneous scheme-comparison and the logging
that was implemented in those functions. The tests for that logging were
also removed.
Differential Revision: https://phabricator.services.mozilla.com/D136229
Firefox background tasks use a new temporary profile directory for
every invocation. We would like to write as little data as possible
into the temporary profile directory in this mode. This patch allows
to make the persistent cookie storage discard cookies just like
private cookie storage.
This approach simply uses that the base `CookieStorage` class is close
to sufficient already. There may be a performance impact with more
virtual invocations, but none of these functions seem likely to be
hot.
Differential Revision: https://phabricator.services.mozilla.com/D139910
Before this change, the collection of typedefs to include in IPDL
protocols was being performed in the _DecorateWithCXXStuff pass of
lower.py. This pass iterates over all included headers, including
recursively, so will also visit headers included by headers you import.
The recursive behaviour caused issues because importing and
forward-declaring imported types is non-recursive, looking at exported
types only one layer deep. This could lead to typedefs being generated
in IPDL protocols referencing types which could never be named by the
IPDL code, and which had no definition in c++, leading to build errors.
This patch changes the logic to instead happen during the
_GenerateProtocolActorCode pass of lower.py, which is also where
required forward declarations and imports are handled, allowing us to
keep the set of typedefs generated more tightly in sync with the actual
set of types available to the actor.
This required some changes in client code which was relying on
incorrectly generated typedefs, however these types have now been fixed.
Differential Revision: https://phabricator.services.mozilla.com/D141032
This Nimbus experiment code was added in bug 1719070 to test if sending a "Firefox 100" UA string causes any major webcompat problems.
The moz.build change was added in bug 1724635 to fix a Thunderbird build break. MOZ_BUILD_APP_IS_BROWSER = true when building Firefox, false when building Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D126408
The idea in this patch is like D99680, but the difference is that mFrecencyArray now contains CacheIndexRecordWrapper.
This should be able to help us track why CacheIndexRecordWrapper is released before removing it from mFrecencyArray.
Differential Revision: https://phabricator.services.mozilla.com/D139469
And in one case, #include "mozilla/ProfilerThreadState.h" where only `AUTO_PROFILER_THREAD_WAKE` is used.
Depends on D140172
Differential Revision: https://phabricator.services.mozilla.com/D140173
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
Automatically generated rewrites of all ParamTraits and IPDLParamTraits
implementations in-tree to use IPC::Message{Reader,Writer}.
Differential Revision: https://phabricator.services.mozilla.com/D140004
This change does not build without the automatically rewritten changes from
part 3c, as every IPC::ParamTraits and IPDLParamTraits implementation needs to
be updated at once, but these are the manual changes which are required and not
handled by the automatic script.
Differential Revision: https://phabricator.services.mozilla.com/D140001
This will allow the types to be more easily automatically substituted in place
of `IPC::Message`, as the type will already be declared in places it is used.
Differential Revision: https://phabricator.services.mozilla.com/D140000
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
With this patch, we'll skip the `RestrictConnections` cehck when creating a speculative connection for Alt-svc validation.
Differential Revision: https://phabricator.services.mozilla.com/D139952
This removes a part of the erroneous scheme-comparison and the logging
that was implemented in those functions. The tests for that logging were
also removed.
Differential Revision: https://phabricator.services.mozilla.com/D136229
When the pc.close() calls in PeerConnection.jsm were removed, tests that did
not explicitly call pc.close() would result in situations where DataChannel
shutdown ran first, which resulted in DataChannels hanging around after
DataChannel ran its global shutdown code. So, we stop using xpcom-shutdown to
prompt DataChannel to shut down, and instead use ShutdownBlockingTicket to
ensure that shutdown does not proceed until DataChannel is cleaned up, which
naturally results from the PeerConnectionCtx shutdown code. However,
ShutdownBlockingTicket blocks xpcom-will-shutdown, not xpcom-shutdown, which
resulted in PeerConnectionCtx not getting an opportunity to run its shutdown
code, which then led to shutdown hangs. So, PeerConnectionCtx runs its shutdown
code at xpcom-will-shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D139210
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Differential Revision: https://phabricator.services.mozilla.com/D138682
While we do so, also add a boolean argument to indicate
if we are in a _Content_ process or some other type of
subprocess, which I expect we will need later.
Differential Revision: https://phabricator.services.mozilla.com/D138681
We want to eventually crash if a blocklisted preference
is accessed. In order to do this, we do need to
populate the preference in the pref hashmap of the
subprocess; otherwise when we look up a blocklisted
pref we will just not find anything. We could try to
put the blocklist check at that point; but this won't
work for StaticPrefs; we'd also need to put the blocklist
check there.
Performing a list iteration and string comparison on
every Static Pref call is not acceptable when we can
just populate a bit and check it.
Differential Revision: https://phabricator.services.mozilla.com/D138679
Because these images are loaded as embeds/objects we can't get a hold of them to apply most usual methods of waiting for decode (img.decode, using a special powers image notifications observer). This should hopefully be enough to avoid hitting this in automation.
Backout the patch for bug 1722422 (the one that changed it from an assert to a leak) because I think it's easier to classify/recognize the assert than the leak in the logs.
Differential Revision: https://phabricator.services.mozilla.com/D139464
The crash happened because gDNSServiceWrapper won't be created if socket process is not used for networking. I missed this case in my previous patches.
So, this patch makes sure that DNSServiceWrapper::SwitchToBackupDNSService won't be called if socket process over networking is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D139320
- nsHttpConnection now has states. Currently only proxy setup phase is added to the states.
- The states are used in nsHttpConnection::OnSocketWritable tto make the code more understandable.
- Some pieces of selfcontained code are extracted from nsHttpConnection::OnHeadersAvailable, i.e. HandleTunnelResponse and HandleWebSocketResponse
Differential Revision: https://phabricator.services.mozilla.com/D138714
Since TRRService::MaybeSetPrivateURI() is the only case that can triggers a new confirmation when TRRService::ReadPrefs() is called, making ConfirmationContext::Handle() returns a boolean value should be enough for this case.
Differential Revision: https://phabricator.services.mozilla.com/D139107
multipart/x-mixed-replace loads don't start a new load for parts other than the first,
they just call OnStartRequest/OnStopRequest for every part. The nsDocShell code was
trying to set the active entry to the loading entry for these loads, but because we
never started a new load after the first part, the loading entry would be null and we'd
just clear the active entry. history.replaceState would then try to replace the active
entry, but finding none it would just add a new one.
Differential Revision: https://phabricator.services.mozilla.com/D138464
The problem here is that the creation of DNS service and setting trr pref is racy.
This problem can be fixed by creating DNS service earlier.
Differential Revision: https://phabricator.services.mozilla.com/D139106
Since both DnsAndConnectSocket and nsHttpTransaction use HttpActivityDistributor, let's refactor this a bit by moving some duplicate code to nsHttpHandler.
This patch also makes it possible to test ECH activity for Http3 case.
Differential Revision: https://phabricator.services.mozilla.com/D138893
The origin test assumes a very particular ordering of HTTP activities, which causes some interimentent failures.
The failed case shows that it's possible that a speculative connection completes before we dispatch the real transaction, so we got 6 http activites.
Differential Revision: https://phabricator.services.mozilla.com/D138892
It seems sfv 0.8.0 is used in the tree, while neqo is using the newer 0.9.1.
Updating http-sfv to use sfv 0.9.1 should remove the code duplication.
Differential Revision: https://phabricator.services.mozilla.com/D139027
Since both DnsAndConnectSocket and nsHttpTransaction use HttpActivityDistributor, let's refactor this a bit by moving some duplicate code to nsHttpHandler.
This patch also makes it possible to test ECH activity for Http3 case.
Depends on D138892
Differential Revision: https://phabricator.services.mozilla.com/D138893
The origin test assumes a very particular ordering of HTTP activities, which causes some interimentent failures.
The failed case shows that it's possible that a speculative connection completes before we dispatch the real transaction, so we got 6 http activites.
Differential Revision: https://phabricator.services.mozilla.com/D138892
1. Check if NeckoParent is still able to send IPC before creating SocketProcessBridge
2. Make sure mPendingEvents always be cleared after launching socket process
Differential Revision: https://phabricator.services.mozilla.com/D138487
These helper methods are similar to the related ones for
nsIInputStream::ReadSegments, and can be used to implement
nsIOutputStream::Write and nsIOutputStream::WriteFrom in terms of
WriteSegments.
There were various places which used manual copies of these methods, which are
being unified.
Differential Revision: https://phabricator.services.mozilla.com/D138334
Tom Ritter
Cristian Tuns
Mathieu Leplatre
Timothy Nikkel
ffxbld
Karl Tomlinson
Nika Layzell
june wilde
Marian-Vasile Laza
Chris Peterson
Molnar Sandor
Cosmin Sabou
Dana Keeler
Kershaw Chang
Jan Rio Krause
Mark Banner
Frederik Braun
Jonathan Watt
Manuel Bucher
Emilio Cobos Álvarez
Kagami Sascha Rosylight
criss
Tim Huang
Gijs Kruitbosch
edguloien
Norisz Fay
Csoregi Natalia
Ryan VanderMeulen
Butkovits Atila
Randell Jesup
Dragana Damjanovic
Tom Schuster
Tom Schuster
Nick Alexander
Noemi Erli
Sebastian Hengst
Olli Pettay
Gerald Squelart
Toshihito Kikuchi
Valentin Gosu
Mathew Hodson
Byron Campen
Andreea Pavel
Narcis Beleuzu
Peter Van der Beken
Sean Feng
Jens Stutte
Henri Sivonen
Jari Jalkanen
Haiyang Xu
Florian Quèze