This function makes it possible to listen for multiple events from the
content process, even when there are frameloader swaps.
This commit also adds a checkFn param to firstBrowserLoaded, which is
useful.
MozReview-Commit-ID: 93ItHIPSGVU
Currently the e10s tab switcher doesn't set the primary="true"
attribute on a browser element until the tab switcher is
destroyed. This means that using the |content| global is unreliable in
e10s since it may take as long as the tab switcher's unload delay
before the attribute changes. Normally this doesn't matter since
|content| isn't useful in e10s. However, tests that use tabs like
about:preferences rely on |content|, and there isn't a good reason to
fix them. So let's just change the attribute immediately upon changing
tabs.
MozReview-Commit-ID: 1cgJbmXD6of
Currently, if you try to use contentDocumentAsCPOW, you'll get an
exception saying that browser code is not allowed to use CPOWs. That's
because we cleverly tried to get the CPOW via
contentWindowAsCPOW.document. However, this property access happens
inside remote-browser.xul, where CPOWs are forbidden. So it doesn't
work.
MozReview-Commit-ID: ANWad4tvGpU
Initial support for CSS variable tooltip. Removed title attribute from
variables and added a new tooltip displaying the same content.
MozReview-Commit-ID: FeHmgiS7KQj
This function makes it possible to listen for multiple events from the
content process, even when there are frameloader swaps.
This commit also adds a checkFn param to firstBrowserLoaded, which is
useful.
MozReview-Commit-ID: 93ItHIPSGVU
Currently the e10s tab switcher doesn't set the primary="true"
attribute on a browser element until the tab switcher is
destroyed. This means that using the |content| global is unreliable in
e10s since it may take as long as the tab switcher's unload delay
before the attribute changes. Normally this doesn't matter since
|content| isn't useful in e10s. However, tests that use tabs like
about:preferences rely on |content|, and there isn't a good reason to
fix them. So let's just change the attribute immediately upon changing
tabs.
MozReview-Commit-ID: 1cgJbmXD6of
Currently, if you try to use contentDocumentAsCPOW, you'll get an
exception saying that browser code is not allowed to use CPOWs. That's
because we cleverly tried to get the CPOW via
contentWindowAsCPOW.document. However, this property access happens
inside remote-browser.xul, where CPOWs are forbidden. So it doesn't
work.
MozReview-Commit-ID: ANWad4tvGpU
Adapted from https://wiki.mozilla.org/SecurityEngineering/NSS_Startup_and_Shutdown_in_Gecko :
Properly implementing the coordinated shutdown of NSS has, to date, proved
intractable. For architectural reasons and due to the significant complexity
involved, the NSS resource tracking and shutdown infrastructure has been an
ongoing source of crashes and hangs in Firefox. To that end, we have been
exploring the possibility of not shutting down NSS at all. For this to work, we
have had to address a number of potential concerns.
Certificate and key database corruption: In theory, if Firefox were to exit
without coordinating with NSS, data stored in the certificate and key databases
(backed by BerkeleyDB) could be lost. To mitigate this, we have migrated to
using the sqlite-backed implementation. The databases are now journaled, and
short of a bug in sqlite, we do not anticipate data loss due to database
corruption.
PKCS#11 devices: In theory, if Firefox were to exit without coordinating with
NSS and thus any attached PKCS#11 devices, data could be lost on these devices.
However, it is our understanding that these devices must be robust against
unexpected physical removal. Uncoordinated shutdown should present no worse a
risk to user data.
FIPS 140-2 mode: While Mozilla does not ship a version of Firefox that supports
FIPS mode out of the box, Red Hat does. It is our understanding that clearing
key material is a requirement of FIPS and that not shutting down NSS may pose a
problem for this requirement. Red Hat's FIPS 140-2 Security Policy[0] specifies
that the application (i.e. Firefox) using the module (i.e. NSS) is responsible
for zeroization of key material. More specifically, it says "All plaintext
secret and private keys must be zeroized when the Module is shut down (with a
FC_Finalize call), reinitialized (with a FC_InitToken call), or when the session
is closed (with a FC_CloseSession or FC_CloseAllSessions call)." Thus, if
Firefox never shuts down NSS, this requirement is trivially met.
Leak detection: By not shutting down NSS, technically we leak some allocated
memory until shutdown. This could cause problems if our test infrastructure
detected and reported these leaks. However, it appears not to (which itself is
somewhat concerning). In any case, we will have to deal with this if and when we
can detect these leaks.
Given that these concerns all have at least a preliminary answer, we will move
forward with attempting to not shut down NSS in Firefox. This may expose
unexpected issues that may lead to a reassessment of the situation, so this will
be on a trial basis only in Nightly.
[0] https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3070.pdf
MozReview-Commit-ID: LjgEl1UZqkC
--HG--
extra : rebase_source : 99bf715f7f6566ec92ca763eefdbd8d2f69d2ba2
extra : amend_source : d4177cc87f54fccbd49312feef7e29b77bf01432
It looks like the main cause of intermittent failures in getDirectory is
that the adb pull command fails because the emulator has hung. For other
commands, we usually handle this by checking the return code and raising
DMError if anything fails. There is mozharness/taskcluster code in
place to automatically retry tasks that throw DMError.
