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
ANGLE cherry-pick: 9088557fe47e0ce1487b248b60acbc740acd7801
D3D11: Fix dirty current value updates.
Fixes a bug where subsequent updates to a "current value" (disabled)
Vertex Attribute would not trigger the state change to D3D11 such that
the updated buffer handle would be applied to D3D11. Also adds a test
to cover the problem case.
This bug was introduced in 2bc947334cad:
"D3D11: Minor optimizations to vertex attribute application."
BUG=chromium:779675
BUG=angleproject:1155
MozReview-Commit-ID: CywgVRYwaKL
This patch fixes several errors in Windows file/path management for
the binjs-decoder jsapi-tests:
- under Windows, files should be explicitly opened as "binary",
otherwise the Windows version of the libc can be creative about
their contents;
- "*.binjs" should not be part of the path;
- I/O functions don't all have the same return value conventions to
notify of an error.
MozReview-Commit-ID: 51rVpRlcUai
--HG--
extra : rebase_source : a7d977c7dc0aecb05c4bbbf4547dedffbd4ec974
Otherwise we will use 48kHz as default, the MSG will resample as needed.
It would be possible to allow all frequencies in the AudioConduit as the webrtc backend supports them all, however it would require more changes and likely heap allocation that we're trying to limit in this part of the code.
MozReview-Commit-ID: B3x5t1FSaQ8
--HG--
extra : rebase_source : 77f83a876ed9b5ded45419245655709aee2573df
Prepare for bug 1426203 export that will include es modules in test files.
MozReview-Commit-ID: 5tdEx8ieTrd
--HG--
extra : rebase_source : 932bf2947fee41a41952b45e586f0332af86f09c
