Don't start the sandbox until after the port exchange so the parent process does not have to wait longer in ContentParent::LaunchSubprocess() for the (expensive) sandbox_init_with_parameters call to complete in the child. Remove the policy rule allowing access to the parent port now that it is already open when the sandbox is initialized and therefore not needed.
Differential Revision: https://phabricator.services.mozilla.com/D11186
--HG--
extra : moz-landing-system : lando
mingw-clang, when using SEH exceptions, compile these fine but don't unwind
them properly. When using sj/lj exceptions it can't compile them at all.
--HG--
extra : histedit_source : 4bda121d4d60ab6e7cf51a3d4287261c81904fe2
Add the /private/var directory to the list of file-read-metadata paths to avoid rendering issues on macOS 10.14 when sandbox early startup is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D9933
--HG--
extra : moz-landing-system : lando
The original threading model of OSKeyStore could lead to a deadlock if an
asynchronous event were dispatched and then the isNSSKeyStore attribute were
queried. This patch removes that pitfall by moving the determination of the
attribute to OSKeyStore rather than the underlying implementation.
Additionally, the original threading model was inefficient in that it created
and destroyed a thread per asynchronous operation. This patch reworks this to
only ever create one worker thread.
Differential Revision: https://phabricator.services.mozilla.com/D9299
--HG--
extra : moz-landing-system : lando
In bug 1475775, we added code to remove the old NSS key DB if the user has set a
password on the grounds that the old DB could potentially be unencrypted and
contain secrets. However, we did so with the assumption that we were using the
new DB, which is not necessarily true when the system has been configured to
always use the old DB, as with some RedHat products. This patch checks for the
existence of the new DB before proceeding with deleting the old DB. Technically
this isn't sufficient, because the new DB could be present even if we're not
using it. However, we've already gone far into "this configuration isn't
supported" territory.
Differential Revision: https://phabricator.services.mozilla.com/D9318
--HG--
extra : moz-landing-system : lando
This patch morphs MasterPassword.jsm to OSKeyStore.jsm while keeping the same
API, as an adaptor between the API and the native API exposed as nsIOSKeyStore.idl.
Noted that OS Key Store has the concept of "recovery phrase" that we won't
be adopting here. The recovery phrase, together with our label, allow
the user to re-create the same key in OS key store.
Test case changes are needed because we have started asking for login in
places where we'll only do previously when "master password is enabled".
This also made some "when master password is enabled" tests invalid because
it is always considered enabled.
Some more test changes are needed simply because they previously rely on the
stable order of microtask resolutions (and the stable # of promises for a
specific operation). That has certainly changed with OSKeyStore.
The credit card form autofill is only enabled on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D4498
--HG--
rename : browser/extensions/formautofill/MasterPassword.jsm => browser/extensions/formautofill/OSKeyStore.jsm
rename : browser/extensions/formautofill/test/browser/browser_creditCard_fill_master_password.js => browser/extensions/formautofill/test/browser/browser_creditCard_fill_cancel_login.js
extra : rebase_source : cabbd8cdec86e5b3965cf1c8b6e635b73b6c2095
extra : histedit_source : 65e71057104465553fefa1d0b293580efed53075
Only allow access to "com.apple.windowserver.active" when the pref
"security.sandbox.content.mac.disconnect-windowserver" is set to true.
Depends on D6721
Differential Revision: https://phabricator.services.mozilla.com/D7357
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command line allowing for early sandbox startup.
Pref'd off behind "security.sandbox.content.mac.earlyinit" until it's ready to be enabled by default.
Once early startup is enabled by default and considered stable, the original sandbox startup code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR. Change APP_PATH to be the path to the parent process .app directory and make GetAppPath return this path when called from the parent or a child process.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
This is a straightforward patch.
Just add a new attribute in nsIProtocolProxyService to indicate whether PAC is still loading. If yes, fail the OCSP request.
Differential Revision: https://phabricator.services.mozilla.com/D9154
--HG--
extra : moz-landing-system : lando
Before this patch, Necko functions polling the state of TLS sockets
(essentially, TransportSecurityInfo) would cause a considerable amount of
locking on TransportSecurityInfo::mMutex instances via GetErrorCode(). Most of
this code only cared if an error had been set via SetCanceled(), so this patch
adds an atomic boolean mCanceled (and associated accessor GetCanceled()) that
can be used to the same effect but without acquiring the lock.
Differential Revision: https://phabricator.services.mozilla.com/D8754
--HG--
extra : moz-landing-system : lando
The compiler warns that jobLevel is uninitialized if none of the if-else
conditions are true. Simply replacing the leading assert with a
"else crash" tells the compiler that case will never actually happen.
Differential Revision: https://phabricator.services.mozilla.com/D8841
--HG--
extra : moz-landing-system : lando
Allow NPAPI sandbox to use restricting SIDs. This hardens the plugin sandbox.
Differential Revision: https://phabricator.services.mozilla.com/D8746
--HG--
extra : moz-landing-system : lando
If nsSecureBrowserUIImpl::OnLocationChange receives a
LOCATION_CHANGE_SAME_DOCUMENT notification, it doesn't need to (and in fact
shouldn't) update its security state or notify downstream listeners.
Differential Revision: https://phabricator.services.mozilla.com/D8900
--HG--
extra : moz-landing-system : lando
The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
In reimplementing the OCSP fetching code in bug 1456489, we improperly
translated an assertion that relied on the nullness of a pointer to rely on the
length of a data structure that was populated by reference. It turns out that
this made the assertion invalid because we could return a successful result and
have filled the data structure with zero-length data and it still would be valid
to operate on (the decoding code returns a malformed input result in this case).
To fix this, we can simply remove the assertion. This patch also adds a test to
exercise this case.
Differential Revision: https://phabricator.services.mozilla.com/D8883
--HG--
extra : moz-landing-system : lando
This patch morphs MasterPassword.jsm to OSKeyStore.jsm while keeping the same
API, as an adaptor between the API and the native API exposed as nsIOSKeyStore.idl.
Noted that OS Key Store has the concept of "recovery phrase" that we won't
be adopting here. The recovery phrase, together with our label, allow
the user to re-create the same key in OS key store.
Test case changes are needed because we have started asking for login in
places where we'll only do previously when "master password is enabled".
This also made some "when master password is enabled" tests invalid because
it is always considered enabled.
Some more test changes are needed simply because they previously rely on the
stable order of microtask resolutions (and the stable # of promises for a
specific operation). That has certainly changed with OSKeyStore.
The credit card form autofill is only enabled on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D4498
--HG--
rename : browser/extensions/formautofill/MasterPassword.jsm => browser/extensions/formautofill/OSKeyStore.jsm
rename : browser/extensions/formautofill/test/browser/browser_creditCard_fill_master_password.js => browser/extensions/formautofill/test/browser/browser_creditCard_fill_cancel_login.js
extra : moz-landing-system : lando
This patch introduces the interface with a stub implementation that does
nothing. Follow-up bugs will add platform-specific implementations.
Differential Revision: https://phabricator.services.mozilla.com/D8480
--HG--
extra : moz-landing-system : lando
Before this patch, if a TLS handshake completed but the server then closed the
connection without reading or writing, Firefox would display a connection reset
error page with a secure lock icon. This is misleading and confusing, so in this
patch, nsSecureBrowserUIImpl::OnLocationChange checks if an error page is being
loaded and sets the state to not secure.
Differential Revision: https://phabricator.services.mozilla.com/D8472
--HG--
extra : moz-landing-system : lando
The desired outcome of this change is that we'll set
`-Wl,--version-script` based on linker kind and not on the output of
`$LINKER -v`.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system `ld` is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system `ld` doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system `ld`.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
Only allow access to "com.apple.windowserver.active" when the pref
"security.sandbox.content.mac.disconnect-windowserver" is set to true.
Depends on D6721
Differential Revision: https://phabricator.services.mozilla.com/D7357
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command
line allowing for early sandbox startup. Limited to Nightly
until confirmed to be stable and ready to ride the trains.
Enable early sandbox startup by default on Nightly and use
pref "security.sandbox.content.mac.earlyinit" to disable
early startup for debugging purposes.
Once early startup is stable, the original sandbox startup
code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
Summary:
Resources that aren't secure (e.g. http) can be routed over secure transports
(e.g. http/2 alt-svc, https proxies). For display purposes (the site identity
widget) we don't want to treat these as secure. Bug 1040323 addressed this exact
issue but didn't include tests. Thus, when nsSecureBrowserUIImpl was
reimplemented in bug 832834, this aspect was neglected. This time, there is a
test.
Reviewers: Gijs
Tags: #secure-revision
Bug #: 1495321
Differential Revision: https://phabricator.services.mozilla.com/D7746
--HG--
extra : rebase_source : e17ec47938f41a692b41a7cf65f1d5e4b880e8a7
extra : amend_source : c445c2f5c7eff94be027e238c2f2befc91b3905a
This patch also switches all GlobalSign EV roots to using the CA/Browser Forum
EV policy OID.
Differential Revision: https://phabricator.services.mozilla.com/D8258
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
This patch removes linux64-jsdcov from the available builds on taskcluster along with any hacks used to run it. It also removes any 'coverage' entries that were added to skip tests.
Differential Revision: https://phabricator.services.mozilla.com/D7919
--HG--
extra : moz-landing-system : lando
The symantec distrust should now ride-the-trains in Firefox 64 Beta and Release.
Set security.pki.distrust_ca_policy to 2.
Differential Revision: https://phabricator.services.mozilla.com/D7745
--HG--
extra : moz-landing-system : lando
Only allow access to "com.apple.windowserver.active" when the pref
"security.sandbox.content.mac.disconnect-windowserver" is set to true.
Depends on D6721
Differential Revision: https://phabricator.services.mozilla.com/D7357
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command
line allowing for early sandbox startup. Limited to Nightly
until confirmed to be stable and ready to ride the trains.
Enable early sandbox startup by default on Nightly and use
pref "security.sandbox.content.mac.earlyinit" to disable
early startup for debugging purposes.
Once early startup is stable, the original sandbox startup
code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
When navigating to an about: page that doesn't exist (e.g.
"about:somethingthatdoesnotexist"), the docShell will call
nsSecureBrowserUIImpl::OnLocationChange with a request that is null.
Consequently, we can't use that to QueryInterface to a nsISecurityEventSink to
call OnSecurityChange. The previous implementation would use the prior
request's nsISecurityEventSink, which was a bug but luckily this produced the
correct behavior. Since the original docShell the nsSecureBrowserUIImpl was
initialized with is what needs to be notified, we can just QueryInterface that
to an nsISecurityEventSink and call OnSecurityChange directly instead.
Differential Revision: https://phabricator.services.mozilla.com/D6951
--HG--
rename : browser/base/content/test/siteIdentity/browser_tls_handshake_failure.js => browser/base/content/test/siteIdentity/browser_navigation_failures.js
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
This patch removes the remaining mozilla-specific dependencies from the
certificate transparency implementation.
Depends on D6845
Differential Revision: https://phabricator.services.mozilla.com/D6846
--HG--
extra : moz-landing-system : lando
In order to make our certificate transparency implementation standalone, we
have to remove mozilla-specific dependencies such as mozilla::Vector.
Depends on D6844
Differential Revision: https://phabricator.services.mozilla.com/D6845
--HG--
extra : moz-landing-system : lando
Put the entire *.firefox.com domain in the list of sites covered by the mozilla services whitelisted roots, which currently include Digicert and Let's Encrypt.
Differential Revision: https://phabricator.services.mozilla.com/D7219
--HG--
extra : moz-landing-system : lando
When navigating to an about: page that doesn't exist (e.g.
"about:somethingthatdoesnotexist"), the docShell will call
nsSecureBrowserUIImpl::OnLocationChange with a request that is null.
Consequently, we can't use that to QueryInterface to a nsISecurityEventSink to
call OnSecurityChange. The previous implementation would use the prior
request's nsISecurityEventSink, which was a bug but luckily this produced the
correct behavior. Since the original docShell the nsSecureBrowserUIImpl was
initialized with is what needs to be notified, we can just QueryInterface that
to an nsISecurityEventSink and call OnSecurityChange directly instead.
Differential Revision: https://phabricator.services.mozilla.com/D6951
--HG--
rename : browser/base/content/test/siteIdentity/browser_tls_handshake_failure.js => browser/base/content/test/siteIdentity/browser_navigation_failures.js
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
The site identity security indicator machinery treats connections where the TLS
handshake failed as insecure (also referred to as "unknown identity"). Before
bug 1468222, such cases were easily detectable as the SSLStatus field of the
relevant nsITransportSecurityInfo would be null. When we merged nsISSLStatus
into nsITransportSecurityInfo, we didn't take this differentiation into account.
This patch brings back the prior behavior by checking if the securityInfo's
securityState indicates that the handshake failed (i.e. it is
STATE_IS_INSECURE).
Differential Revision: https://phabricator.services.mozilla.com/D6316
--HG--
extra : moz-landing-system : lando
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
A previous patch in this bug made the incorrect assumption that we had disabled
the family safety root detection/importing feature by default. In reality, we
enabled it by default in bug 1282871.
In bug 1487258 we moved enterprise root loading to a background thread so as to
not block the main thread. This patch does the same with the family safety
feature.
Differential Revision: https://phabricator.services.mozilla.com/D5484
--HG--
extra : moz-landing-system : lando
I also changed security/certverifier/moz.build a bit while I am here:
* Using '-Xclang' to pass through '-Wall' on clang-cl.
* Now clang-cl will take clang/gcc path because most '-wd****' options have no
effect on clang-cl. '-wd4010' will have an effect, but we already have the
corresponding clang/gcc option ('-Wno-unused-parameter').
--HG--
extra : source : df566a1bd9087cc0bfc03fe19fd9d21bf58f5d9c
nsIAssociatedContentSecurity and nsISecurityInfoProvider are unused as of
bug 832834, so this patch removes them.
Differential Revision: https://phabricator.services.mozilla.com/D5693
--HG--
extra : moz-landing-system : lando
Each instance of CERTCertList creates a PLArena with a chunk size of 2048 bytes,
but only needs space for 3 pointers per certificate in the list. The majority of
the time Gecko uses CERTCertList, we'll store ~3 certificates (although in some
cases we do store a few hundred, such as in tests or the certificate manager).
This is fairly inefficient. This patch starts the process of avoiding using
CERTCertList in Gecko by converting nsNSSCertList (i.e. nsIX509CertList) (as
well as nsNSSCertListEnumerator) to use a more efficient data structure to hold
references to certificates long-term. Future follow-up patches could (and
should) update certificate verification APIs in PSM to avoid CERTCertList as
well.
Depends on D5096
Differential Revision: https://phabricator.services.mozilla.com/D5097
--HG--
extra : moz-landing-system : lando
nsIX509CertList.getRawCertList is only used once and doesn't provide
particularly unique functionality (its one use can easily be re-worked in terms
of other APIs). Removing this API will ease refactoring work to avoid holding
long-lived references to CERTCertList instances in nsNSSCertList.
Differential Revision: https://phabricator.services.mozilla.com/D5096
--HG--
extra : moz-landing-system : lando
Background here is that we are disabling a piece of the downgrade protection in TLS 1.3 and we want to turn it on. We don't know if that is safe, so a pref (and an associated experiment) seems prudent. This is that pref.
Differential Revision: https://phabricator.services.mozilla.com/D4629
--HG--
extra : moz-landing-system : lando
Several source files use DLL_PREFIX/DLL_SUFFIX defines, and they all set
them in moz.build using `DEFINES`. This is problematic for the WSL
build because the quoting gets lost somewhere between bash and cl.exe.
We cannot simply set them globally in moz.configure because their
stringified definitions would conflict with the `set_config` of
DLL_PREFIX/DLL_SUFFIX. Therefore, we globally define
MOZ_DLL_PREFIX/MOZ_DLL_SUFFIX and change all define-related uses of
DLL_PREFIX/DLL_SUFFIX to use their MOZ-equivalents instead.
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
As of bug 1346297, we don't collect telemetry for the family safety root
feature. At this point, it makes the most sense to disable the entire feature by
default.
Differential Revision: https://phabricator.services.mozilla.com/D4994
--HG--
extra : moz-landing-system : lando
As of bug 1346297, we don't collect telemetry for the family safety root
feature. At this point, it makes the most sense to disable the entire feature by
default.
Differential Revision: https://phabricator.services.mozilla.com/D4994
--HG--
extra : moz-landing-system : lando
Loading enterprise roots could potentially take a while, so we certainly
shouldn't do it on the main thread at startup. Note that this doesn't address
the case where a user enables the feature while Firefox is running. This isn't
great but since it's an about:config preference rather than a first-class
preference exposed in about:preferences, we can probably get away with it for
now.
Differential Revision: https://phabricator.services.mozilla.com/D4708
--HG--
extra : moz-landing-system : lando
It turns out nsSecureBrowserUIImpl is considerably more complicated than it
needs to be. This patch reimplements it in terms of OnLocationChange only, which
is all it needs to produce the same behavior as before.
Differential Revision: https://phabricator.services.mozilla.com/D3548
--HG--
extra : moz-landing-system : lando
