In the test of temporary installation of webextension experiments,
the test certificate shim code was marking the test addon as
privileged which allowed it to be loaded, fix that here.
MozReview-Commit-ID: IaZshrMNr3v
--HG--
extra : rebase_source : 34bcd94c6e687c63aadce7cb8d6b07a9ce525597
CPU is only used on Windows, for TimeTicks::HighResNow, but the latter
is not used, so remove them all.
MozReview-Commit-ID: CvV1gMrVRA5
--HG--
extra : rebase_source : 2a512e2cfbe7d734a2c806214a2a96f79cbc9f11
Also changes gSeccompTsyncBroadcastSignum to an atomic, in case these
wrappers race with starting the sandbox, and optimizes the wrappers
slightly by avoiding unnecessary copying of signal sets or sigactions.
Tested by manaully LD_PRELOADing libmozsandbox in the parent process,
because it already has a few signal handlers with block-by-default
masks.
MozReview-Commit-ID: CiHsA6rOCrQ
--HG--
extra : rebase_source : 176c156116a44fb8dff3a5f421499b7e61175047
This makes the pres shell be notified as the last observer unconditionally.
In practice this doesn't matter, and it may already be the case if an iframe
goes display: none and back. In practice, the only dependency that requires this
order is that the pres shell needs to be notified _after_ the content sink, so
we don't try to enter frame construction before beginning the shell update.
That may be worth looking into, but definitely not in the scope of this bug... :)
MozReview-Commit-ID: 9WeJ5kaUtBq
--HG--
extra : rebase_source : 6589df0aa8a875dc270894fabb6b4bc170d6b6fe
Both the cc crate and the rust compiler may want to use "cc", which,
on automation, points to the system GCC compiler instead of ours.
As a workaround, we add a cc symbolic link in the GCC toolchain artifact
so that, as long as the GCC toolchain artifact's bin directory is in
$PATH early enough, it's picked over /usr/bin/cc.
--HG--
extra : rebase_source : 53cacf8a750539706a484218e168c8c9e0ba49a6
The "contract" for toolchains is that extracting foo.tar.xz creates a
directory named foo/. That is however not true for mingw32.tar.xz, which
extracts into gcc/, possibly overwriting files from the gcc.tar.xz
archive (which is also used for mingw builds, for the host part).
This is also not true for nsis.tar.xz, but it reportedly has problems
when it's not in the same directory as mingw32.
But mingw32 doesn't actually need to be mixed with gcc, so it's better
to separate them as they are supposed to be.
--HG--
extra : rebase_source : 30d90af64459bbb31bc076e48f3c661fa9cd4a79
Prior to bug 1224450, CompileDB used data from the Makefiles to generate
the compilation command-lines. Now that the data is derived entirely
from moz.build, we don't need to check that the Makefile is present.
This enables a simple "ac_add_options --build-backends=CompileDB"
mozconfig to work without building a make backend first.
MozReview-Commit-ID: 9tYumyUyg5Y
--HG--
extra : rebase_source : 979f729076b3ab4fd719924877b7ef195e34bfd7
The PATH defined for mingw builds was cargo culted, lacks
/usr/local/bin, and contains things that are pretty much useless these
days, now that we're off buildbot. Similarly, LD_LIBRARY_PATH is
useless.
While many other similar changes could be done to the other mozharness
configurations, figuring out which ones are used under what
circumstances is more work than I'm ready to put (I started, but I
stopped when I encountered jobs that don't even run on try or central).
--HG--
extra : rebase_source : dbcbcf9ba80ebb2858c3d47a186daa367afa2988
The call stack where this assertion would otherwise fail is as follows:
KeyframeEffectReadOnly::UpdateProperties
KeyframeEffectReadOnly::DoUpdateProperties
KeyframeEffectReadOnly::BuildProperties
KeyframeUtils::GetAnimationPropertiesFromKeyframes
KeyframeUtils.cpp::GetComputedKeyframeValues
KeyframeEffectReadOnly::EnsureBaseStyles
In bug 1407898 we made GetComputedKeyframes return an empty list when the pres
context is nullptr so if we get a null pres context in EnsureBaseStyles (which
uses the same method for getting the pres context:
nsContentUtils::GetContextForContent) we know that |aProperties| will be empty.
Also, if |aProperties| is empty we're not going to dereferences |presContext| so
we don't need to assert that it is non-null.
I have not included the crashtest in this patch for the same reason as described
in bug 1407898 comment 6.
MozReview-Commit-ID: 6OZ2yJfRLMV
--HG--
extra : rebase_source : b2a711a54623ea177560cf1b69b3c332654bc938
