At least when the animation-name length is bigger than the animation properties,
we mess up inheritance and only set properly the specified counts, then don't
cycle it.
The nicer fix for this is making these vectors properly, and move the cycling
logic at used-value time (bug 1420928). Same for transitions.
Bug: 1426246
Reviewed-by: hiro
MozReview-Commit-ID: 3cguzIvfMFU
Source-Repo: https://github.com/servo/servo
Source-Revision: 9a4a2b07aa15efe3c41debb3ec199557694c4d62
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : dceaa7f7ba61fc5fcbc998f14ec4950bdab055ba
This allows the flattened tree to have a reasonable state before content
removals, allowing us to fix bugs like bug 1420533.
This used to be also the old setup, but was changed in bug 382376, since the
frame constructor used to reconstruct stuff synchronously. This used to break
all sorts of stylo invariants, and I fixed this in bug 1389743, so now the order
can be sane again.
MozReview-Commit-ID: K2pTweGKSq0
--HG--
extra : rebase_source : e53b7314f39f9c1c2e87fbe202f64b06e4c64c57
This code was relying on nsImageFrame::ContentRemoved running before it.
MozReview-Commit-ID: Imjhd9exjQS
--HG--
extra : rebase_source : 7c6367f515dc140176e50d959c07250057e28354
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
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
