Firefox essentially does not support running NSS in FIPS mode any longer. This
has always been the case on Android from what I can tell and it has been the
case on OS X since at least version 34 (see bug 1047584). It became the case on
Windows as of version 53 (see bug 1295937). Unfortunately, before this patch,
if a user attempted to run an affected version of Firefox using a profile
directory containing an NSS database collection that had FIPS enabled, NSS
initialization would fail and fall back to running in no DB mode, which had the
side-effect of making any saved passwords and certificates unavailable. This
patch attempts to detect and work around this failure mode by moving the
PKCS#11 module DB (which is where the FIPS bit is set) to a backup location and
basically running with a fresh, non-FIPS module DB. This allows Firefox to
initialize NSS with the preexisting key and certificate databases available.
MozReview-Commit-ID: 1E4u1ngZyRv
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting.js => security/manager/ssl/tests/unit/test_broken_fips.js
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key3.db => security/manager/ssl/tests/unit/test_broken_fips/key3.db
extra : rebase_source : 887f457e998d6e57c6536573fbe3cb10547fe154
There appear to be no in-tree users of this function and it references
"b2g." I'm pretty sure it is dead code.
MozReview-Commit-ID: EHHRQ2iqQoP
--HG--
extra : rebase_source : ec136063dc5e4243232fce5289a8f47bd925b481
We shouldn't be running any Firefox OS automation.
MozReview-Commit-ID: 4ea9SL7jill
--HG--
extra : rebase_source : 6d5c457d14d9d2b2b4abda47a2b3bfa1fa745d36
We shouldn't be running any automation related to Firefox OS. We should
be able to delete these files.
MozReview-Commit-ID: SY5f0GD9NQ
--HG--
extra : rebase_source : 3b7b5b28bc5da554ad9082c1c3115b3ab8de2e0a
These were the last occurrences of "gaia" in the mozharness directory.
MozReview-Commit-ID: 8ACEw1rMoUS
--HG--
extra : rebase_source : b5d98c9166d75a83f5303ee0faa34484b6f998d3
This is functionally equivalent since one variant of the
PushStackingContext was already delegating to the other (in
DisplayListBuilder).
MozReview-Commit-ID: 8PfMm3bHeSZ
This class is a RAII class that can be used to push a stacking context
with properties from a WebRenderLayer. It can also then be used to
convert rects in the layer coordinate system to be relative to the
stacking context, which is what we want for passing to WR.
MozReview-Commit-ID: 1WVrfRYqLqc
As we are often converting from LayoutDevicePixel to LayerPixel types
in WebRenderDisplayItem code, I added a convenience overload of
RelativeToParent that takes a LayoutDeviceRect and returns a LayerRect,
even though this is a potential footgun if abused.
MozReview-Commit-ID: DABAWdOBsbV
This extracts a strongly-typed ClipRect() function from GetWrClipRect.
GetWrClipRect is left as a weakly-typed wrapper for existing call sites,
and also does the necessary reference point conversions.
MozReview-Commit-ID: EuyzYIYLR6S
This moves the bulk of the meaningful work done by GetWrRelBounds into
strongly-typed helper functions. GetWrRelBounds is left as a wrapper so
call sites don't need to be updated yet. Note also that the
strongly-typed functions do not do any conversions from one reference
point from another (e.g. by calling the RelativeToXXX functions).
MozReview-Commit-ID: B3nPbOJOf9o
Since the longString object has an actor property which can change from test to test,
replace it with its value in the existing packet.
MozReview-Commit-ID: CzxX203TdEU
--HG--
extra : rebase_source : df89c67ba760ab48b3e5e9e38378314e06dfc0fb
The test doesn't verify that the exceptions are reported to the browser console,
but I manually checked that they are. Adding a test for that part could be
pretty annoying.
