Both tests fail on WebRender without the fix in this patch series.
In the delay phase, those animations should be painted using non-animated
value (i.e. opacity:0 or translateX(100px)), but on WebRender they were painted
using opacity: 1 or identity transform.
MozReview-Commit-ID: DOHopfleWB0
--HG--
extra : rebase_source : 1075557f04d4ae1ce049e2c4513b00287ee9d4be
This function is no longer used since we introduced TransactionWrapper class in
bug 1451469.
MozReview-Commit-ID: FGxi6thbxcP
--HG--
extra : rebase_source : ef5628f8bffb5c1fedf6de80056d4ebba41a9edf
This adds an assertion checking for duplicate items whenever we create an item, and when we merge an item into the final list.
I had to disable tracking for the anonymous inner list for nsDisplayPerspective and nsDisplayTransform (and manually forward RemoveFrame to them), as well as skipping the assertion for multi-page (since we can end up duplicating wrap lists, but isn't a problem, since we don't retain these).
MozReview-Commit-ID: 4n6rx9bQNan
--HG--
extra : rebase_source : 49da303965d63258f4c6023a0b09ef0de7553724
This also changes many references to the 'pseudo stack' to refer to the 'label
stack' instead. The label stack is one of the two stacks that are managed by
the profiling stack, the other stack being the JS interpreter stack.
MozReview-Commit-ID: Ed0YMMeCBY8
--HG--
extra : rebase_source : 5675d670f424c7d7dda04bafc2b3431fa2485e3c
The term "entry" is already used for elements in the profile buffer.
MozReview-Commit-ID: 1aB22V6veQh
--HG--
extra : rebase_source : c664eb4d6bed6cb74ba8a1b67ea99bd8ca57bcf7
extra : source : 3264c0cc0027b240b55bd3aebf27263b1e1d1cc0
Add back font whitelist rules removed by the fix for bug 1393259
to workaround font sandbox extensions not being issued automatically
on OS X 10.11 and earlier.
MozReview-Commit-ID: 2hT0BzN3Ggq
--HG--
extra : rebase_source : 4fe9ce43eb7efe0c6a91c908c149126da6eb708e
Our normal ubuntu 16.04 test image is suitable for hosting an Android x86
emulator with these minor updates: Install kvm and make sure /dev/kvm
rw permissions are open for everyone. Note that /dev/kvm is generally
only visible when running docker with --privileged; its permissions
cannot be modified in the Dockerfile, only at run-time: run-task is the
first opportunity.
test_build.py fails on local builds with messages like:
make[4]: Entering directory '/tmp/tmp65BjCH'
make[4]: *** No rule to make target 'buildid.h'. Stop.
make[4]: Leaving directory '/tmp/tmp65BjCH'
/home/froydnj/src/gecko-dev.git/config/faster/rules.mk:76: recipe for target '/tmp/tmp65BjCH/buildid.h' failed
make[3]: *** [/tmp/tmp65BjCH/buildid.h] Error 2
make[3]: *** Waiting for unfinished jobs....
make[4]: Entering directory '/tmp/tmp65BjCH'
make[4]: *** No rule to make target 'source-repo.h'. Stop.
make[4]: Leaving directory '/tmp/tmp65BjCH'
/home/froydnj/src/gecko-dev.git/config/faster/rules.mk:76: recipe for target '/tmp/tmp65BjCH/source-repo.h' failed
make[3]: *** [/tmp/tmp65BjCH/source-repo.h] Error 2
make[3]: Leaving directory '/tmp/tmp65BjCH/faster'
Makefile:155: recipe for target 'faster' failed
The tests pass in automation, however, because automation always defines
the rules for buildid.h and source-repo.h in the toplevel Makefile.in.
For local builds, however, those rules are not defined to avoid build
churn. Let's ensure that the necessary rules are defined during testing
as well.
The build system knows at build-backend time where to find each IDL
file; making xpidl-process.py rediscover this by requiring
xpidl-process.py to search through directories to find input IDL files
is silly. To rememdy this, we're going to modify things so full paths
are passed into the script. Those paths can then be used directly, with
no searching.
The tail end of the xpidl Makefile.in contains a line, generated for
every xpt file:
$(1): $(addsuffix .idl,$(addprefix $(dist_idl_dir)/,$($(basename $(notdir $(1)))_deps)))
This line, in context, is saying that the xpt file depends on all of its
input IDL files. But xpidl-process.py already generates this
information when we pass it --depsdir, which we do. So this code is
redundant with what we already generate, and it can be removed.
The previous patch required us to pass a single -I argument pointing at
$(DIST)/idl so IDL include statements would work correctly. This patch
lifts that limitation and explicitly points xpidl-process.py at the
locations of all the IDL source directories to search for included IDL
files. Invocations of xpidl-process.py no longer depend on IDL files
being copied to the objdir.
Building on the last patch, we can change the build process to pass in
the directories where the input IDL files can be found. It is
convenient to pass in just the relative source directory paths, to
encourage people to not look in the object directory and to make the
command lines slightly shorter.
xpidl-process.py still assumes that included IDL files can be found by
looking in a single directory. We add a single -I argument to the
invocation of xpidl-process.py to accommodate this short-sightedness.
The current IDL build setup assumes that all IDL files can be found in a
single directory. This setup requires that all IDL files be copied to a
single directory, which is suboptimal in terms of disk I/O and also
complicates things like generating IDL files at build time.
As a first step in moving away from this state of affairs,
xpidl-process.py needs to be taught that the input IDL files could
potentially be found in multiple directories. The current setup can
just specify $(DIST)/idl as the lone directory to examine. Future
patches will change this to examine multiple directories.
This method is only called in one place, and it doesn't pass
allow_existing. Whatever ugly thing this keyword was working around
doesn't exist anymore, so let's get rid of it.
Hiroyuki Ikezoe
arthur.iakab
Chris AtLee
Matt Woodrow
Markus Stange
Kartikaya Gupta
Haik Aftandilian
Dorel Luca
Geoff Brown
Andrea Marchesini
Jan de Mooij
Dão Gottwald
Drew Willcoxon
Tokio Kajitsuka
Ben Kelly
Jonathan Kew
J.C. Jones
Nathan Froyd
Eugen Sawin
Benjamin Bouvier
Alexander Surkov