In strict fallback mode, confirmation should still catch cases when the provider is
unavailable for whatever reason, and after that we should just fall back. This was
missing from bug 1714182.
Differential Revision: https://phabricator.services.mozilla.com/D126168
This patch:
- moves the AutoNestedEventLoopAnnotation into SpinEventLoopUntil.h
- introduces the motivated SpinEventLoopUntil
- maps remaining SpinEventLoopUntil instances to SpinEventLoopUntil with "Missing motivation."
- changes relevant uses in nsThread and nsThreadManager to the motivated SpinEventLoopUntil
- changes all uses with IgnoreAndContinue behavior to the motivated SpinEventLoopUntil
Differential Revision: https://phabricator.services.mozilla.com/D126714
In strict fallback mode, confirmation should still catch cases when the provider is
unavailable for whatever reason, and after that we should just fall back. This was
missing from bug 1714182.
Differential Revision: https://phabricator.services.mozilla.com/D126168
This patch:
- moves the AutoNestedEventLoopAnnotation into SpinEventLoopUntil.h
- introduces the motivated SpinEventLoopUntil
- maps remaining SpinEventLoopUntil instances to SpinEventLoopUntil with "Missing motivation."
- changes relevant uses in nsThread and nsThreadManager to the motivated SpinEventLoopUntil
- changes all uses with IgnoreAndContinue behavior to the motivated SpinEventLoopUntil
Differential Revision: https://phabricator.services.mozilla.com/D126714
By default nsIPermissionManager will not persist data in private browsing.
There are cases however, like private-only-browser Firefox Focus, where we
would want to be able to persist tracking protection exceptions permanently.
This patch adds a new method called
`addFromPrincipalAndPersistInPrivateBrowsing` which allows setting permanent
permissions in private browsing..
Differential Revision: https://phabricator.services.mozilla.com/D126544
If amount of origins that have early-data disabled exceeds certain amount, disable early-data for all origins
This is controlled by prefs.
Differential Revision: https://phabricator.services.mozilla.com/D126555
Simply converting the argument to a string could lead to odd situations where
resolving `null` succeeds if a hostname called "null" exists on the network.
Differential Revision: https://phabricator.services.mozilla.com/D126468
In bug 1626057 we added support for steering. There we made the distinction
between a default network.trr.uri pref, and a user-set one by using
`Preferences::HasUserValue`. However, it seems that enterprise policies change
the default branch of the pref, so this would lead to it having a lower
priority than DoHRollout or steering.
In bug 1713036 we introduced `network.trr.default_provider_uri` and made
`network.trr.uri` an empty string, so checking hasUserValue isn't required
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D126961
This is needed to make sure the experimental User Agent string is applied immediately after starting the browser, not just whenever the Nimbus data changes as part of the NimbusFeatures::OnUpdate handler.
Differential Revision: https://phabricator.services.mozilla.com/D126774
To differentiate the storage permission is granted by either the
permission or the allowList, we need to change the hasStoragePermission
to an enum to represent the storage permission state.
This patch also changes the name of the attribute to make it reasonable
with respect to this change.
Differential Revision: https://phabricator.services.mozilla.com/D126276
Before this bug TLS handshake was only driven by forcing writes. SecurtyInfo was set during a write code path. That is not anymore true and the TLS handshake can be driven by reading from a socket. That causes an issue where the SecurtyInfo was not set in case a TLS handshake fails. This bug added the setting of the SecurtyInfo to the read code path, but that causes problems when the transaction is closed due to corrupted response.
This patch fixes this by moving the setting of SecurtyInfo to Close() function.
Do not call HandshakeDoneInternal if the connection has been closed between posting the HandshakeDoneInternal runable and executing it.
Differential Revision: https://phabricator.services.mozilla.com/D125666
In this case necko should poll for read (not for write) and reset the poll flags when the handshake is done.
The other option is to inspect the resumption ticket before adding it to the nss socket and find out which alpn will be used and disable the early-data if the version is http/1.1 and the transaction cannot send early-data. This currently only works on Nightly. When we roll out the necko’s token cache we can consider making this change.
Additional changes:
Consolidate mEarlyDataNegotiated and mWaitingFor0RTTResponse into mEarlyDataState
Differential Revision: https://phabricator.services.mozilla.com/D123928
HandshakeDone will be called after a handshake is finished and also after the certificate verifications are done.
The code relies on HandshakeDone to signal that the handshake is done. When early-data is not available HandshakeDone is responsible for setting up a Http2 session if needed. There are 2 outcomes when early-data is used:
1) early-data is accepted and transaction continues polling for read,
2) early-data is rejected. In this case, the transaction is restarted as well as polling flags, i.e. the connection will stop polling for read and start polling for write.
Another difference is that a transaction that is started during the early-data period will behave as a normal transaction, i.e. it will write data and continue polling for read to receive response. The special cases during early-data(mWaitingFor0RTTResponse==true) are removed from nsHttpConnection::OnSocketWritable().
EnsureNPNComplete is only responsible for driving handshake and checking the early-data availability. All logic for finishing a handshake (i.e. checking whether early-data is accepted and checking alpn value) has been moved to HandshakeDone.
The patch also extracts FinishNPNSetup that is responsible for the bookkeeping after a handshake is done or fails, e.g. resetting transactions if 0Rtt is used but handshake fails, updating timings and sending telemetry.
HandshakeDone needs to be dispatched so that it is not called inside nss locks. The side effect of this is that nsHttpConnection::OnSocketWritable() may be called in between HandshakeDone being dispatched and executed. Therefore we still need to keep CheckCanWrite0RTTData(). This can be fixed in a follow up patch.
Side cleanups:
Remove mNotTrustedMitmDetected - his was used for ESNI, but it is not used anymore
Differential Revision: https://phabricator.services.mozilla.com/D123824
Extract Check0RttEnabled
The old code checks 0RTT state then does a DriveHandshake then checks 0RTT again. This is done in this way because before DriveHandshake is called for the first time 0RTT states are not set. DriveHandshake is sometimes called as a side effect by IsAlive() check. The new code makes this less complex and just calls DriveHandshaek before checking 0RTT.
Extract code for setting 0RTT telemetry values.
Remove some code that set timing because the same code is called a bit later again.
Differential Revision: https://phabricator.services.mozilla.com/D123645
Before this patch, we fetch HTTPS RR in `nsHttpChannel::MaybeStartDNSPrefetch`, which is too early. It's possible that this http request is blocked by an extension but we still send the query for HTTPS RR.
To improve this, we move the time of fetching HTTPS RR a bit late.
Differential Revision: https://phabricator.services.mozilla.com/D125931
Since `nsHttpTransaction::mConnection` could be `Http2Session` and `Http2Session` supports weak reference, we should make sure `Http2Session` to be always released on socket thread.
Differential Revision: https://phabricator.services.mozilla.com/D125510
Before this bug TLS handshake was only driven by forcing writes. SecurtyInfo was set during a write code path. That is not anymore true and the TLS handshake can be driven by reading from a socket. That causes an issue where the SecurtyInfo was not set in case a TLS handshake fails. This bug added the setting of the SecurtyInfo to the read code path, but that causes problems when the transaction is closed due to corrupted response.
This patch fixes this by moving the setting of SecurtyInfo to Close() function.
Do not call HandshakeDoneInternal if the connection has been closed between posting the HandshakeDoneInternal runable and executing it.
Differential Revision: https://phabricator.services.mozilla.com/D125666
In this case necko should poll for read (not for write) and reset the poll flags when the handshake is done.
The other option is to inspect the resumption ticket before adding it to the nss socket and find out which alpn will be used and disable the early-data if the version is http/1.1 and the transaction cannot send early-data. This currently only works on Nightly. When we roll out the necko’s token cache we can consider making this change.
Additional changes:
Consolidate mEarlyDataNegotiated and mWaitingFor0RTTResponse into mEarlyDataState
Differential Revision: https://phabricator.services.mozilla.com/D123928
HandshakeDone will be called after a handshake is finished and also after the certificate verifications are done.
The code relies on HandshakeDone to signal that the handshake is done. When early-data is not available HandshakeDone is responsible for setting up a Http2 session if needed. There are 2 outcomes when early-data is used:
1) early-data is accepted and transaction continues polling for read,
2) early-data is rejected. In this case, the transaction is restarted as well as polling flags, i.e. the connection will stop polling for read and start polling for write.
Another difference is that a transaction that is started during the early-data period will behave as a normal transaction, i.e. it will write data and continue polling for read to receive response. The special cases during early-data(mWaitingFor0RTTResponse==true) are removed from nsHttpConnection::OnSocketWritable().
EnsureNPNComplete is only responsible for driving handshake and checking the early-data availability. All logic for finishing a handshake (i.e. checking whether early-data is accepted and checking alpn value) has been moved to HandshakeDone.
The patch also extracts FinishNPNSetup that is responsible for the bookkeeping after a handshake is done or fails, e.g. resetting transactions if 0Rtt is used but handshake fails, updating timings and sending telemetry.
HandshakeDone needs to be dispatched so that it is not called inside nss locks. The side effect of this is that nsHttpConnection::OnSocketWritable() may be called in between HandshakeDone being dispatched and executed. Therefore we still need to keep CheckCanWrite0RTTData(). This can be fixed in a follow up patch.
Side cleanups:
Remove mNotTrustedMitmDetected - his was used for ESNI, but it is not used anymore
Differential Revision: https://phabricator.services.mozilla.com/D123824
Extract Check0RttEnabled
The old code checks 0RTT state then does a DriveHandshake then checks 0RTT again. This is done in this way because before DriveHandshake is called for the first time 0RTT states are not set. DriveHandshake is sometimes called as a side effect by IsAlive() check. The new code makes this less complex and just calls DriveHandshaek before checking 0RTT.
Extract code for setting 0RTT telemetry values.
Remove some code that set timing because the same code is called a bit later again.
Differential Revision: https://phabricator.services.mozilla.com/D123645
Previously we called `ProcessCrossOriginEmbedderPolicy` in
`nsHttpChannel::ContinueProcessResponse1`, but we only loaded the cached
response headers in `ContinueProcessResponse3`, meaning that we incorrectly
reported a missing header for the revalidated resource.
This change moves the header checking calls to `ContinueProcessNormal` and
`AsyncProcessRedirection` instead, so they get executed after processing
the cached headers.
Differential Revision: https://phabricator.services.mozilla.com/D125184
The goal here is to ensure we can always rely on `AppShutdown::GetShutdownPhase` to be in sync with the "real" application status, mainly this was needed for xpcshell tests to not break if we add assertions on our shutdown state on some global singletons.
We keep the existing observer notification topics but force them (on the parent process) to be issued through the new `advanceShutdownPhase` function of the startup service using the `ShutdownPhase` enum. This way we can synchronize `AppShutdown`'s internal status accordingly.
Some further notes:
# The `MOZ_ASSERT(AppShutdown::IsNoOrLegalShutdownTopic(aTopic));` in `NotifyObservers` helped a lot to identify missing cases. I think we should keep it in order to stay safe.
# Introducing the `cenum IDLShutdownPhase` helps to keep the knowledge about the mapping from shutdown phases to observer topics exclusively inside AppShutdown.cpp. Still callers must know what they do in order to choose a proper phase, of course.
# However we must be aware that `AppShutdown` this way can be kept in sync with the shutdown notifications only in the parent process and that `GetCurrentShutdownPhase` might not give the correct result in child processes. We might want to file a follow up bug that adds some asserts to avoid improper use of `AppShutdown` functions in child processes (but I do not want to make this patch bigger as needed to solve the blocking dependency for bug 1697972).
# The socket process is one example of a child process that "overloads" shutdown topics. I was wondering if it is the right call to use the very same topic names here to request shutdown to the socket process or if it should have its own topics. Those topics triggered the assert and thus I had to disable it for child processes, for now.
# This goes together with the more general approach to define process type specific shutdown phases (and hence mappings to topics) as drafted very roughly in bug 1697745.
# This patch seemed to trigger a known intermittent more often, thus the change here in `ServiceWorkerManager`.
Differential Revision: https://phabricator.services.mozilla.com/D124350
We add the new content policy here, but leave the behavior as TYPE_OTHER, so
we can verify that the new test fails before the fix is applied.
Differential Revision: https://phabricator.services.mozilla.com/D124965
This new pref will be used on android to enable high-value-only process
isolation. An initial version of high-value-only process isolation is
also implemented in this bug, using the permission manager to track
whether a site is high-value due to having served a
`Cross-Origin-Opener-Policy` header.
Future high-value permissions due to things like logging into a site and
OAuth flows can be tracked in the same way, by adding the permission to
the permissions database.
In the future, it might be valuable to provide UI for visualizing what
sites are considered high-value at any point in time, but this works
fine for now.
Differential Revision: https://phabricator.services.mozilla.com/D123127
This can happen during shutdown, when in `nsHttpNegotiateAuth::GetOrCreate()`
we assign `gSingleton` to a `new nsHttpNegotiateAuth` object but then it gets
cleared immediately by `mozilla::ClearOnShutdown` because we're already
shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D124893
Without the pref enabled, DocumentLoadListener is destroyed when
DocumentChannelParent is destroyed. With the pref enabled, we create
DocumentLoadListener when we are trying to do a parent controlled navigation,
but it does not get destroyed anywhere. To do that, we can disconnect the
DLL listeners before we trigger redirection to the real channel and resume the
load.
Differential Revision: https://phabricator.services.mozilla.com/D122131
This field will be useful to JS code such as JSWindowActors which need to be
able to detect when their WindowContext is no longer active.
Differential Revision: https://phabricator.services.mozilla.com/D124098
There were a number of crashes caused due to a hang on a background
TaskQueue, and in many of these bugs there was a read from
BackgroundFileSaver on the stack. It appears that we are stuck in this
loop late in shutdown, when we are attempting to shut down TaskQueues
and XPCOM threads.
I'm unsure if we would cancel these requests already, however I noticed
that we wouldn't abort this read even if we did. This change now
performs a check to see if the BackgroundFileSaver has errored between
each read, which should cause aborts to also abort this loop, and
hopefully avoid potential shutdown hangs.
Differential Revision: https://phabricator.services.mozilla.com/D124123
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
Nihanth Subramanya
ffxbld
Manuel Bucher
Rob Wu
Jens Stutte
june wilde
Butkovits Atila
Marian-Vasile Laza
Agi Sferro
Csoregi Natalia
Alexandru Michis
lyavor
Noemi Erli
Valentin Gosu
Gijs Kruitbosch
Emilio Cobos Alvarez
Dragana Damjanovic
Kershaw Chang
Olli Pettay
Dennis Schubert
Tim Huang
Shane Caraveo
Sean Feng
Narcis Beleuzu
Christoph Kerschbaumer
Yury Delendik
Cristian Tuns
Sandor Molnar
Byron Campen
Mark Banner
Michelle Goossens
Nicklas Boman
Benjamin Peterson
Ben Hearsum
Nika Layzell
Anny Gakhokidze
Florian Quèze
Jan Varga
Agi Sferro
Iulian Moraru
Paul Zuehlcke
Andi-Bogdan Postelnicu