Previously we used the tweakExpectedRestyleCount function (replaced by the
waitForAnimationReadyToRestyle function in the previous patch) only in cases
where we were actually expecting restyles to happen. For cases where we don't
expect restyles, i.e. cases where we assert the restyle count is zero, we
didn't use this method meaning we didn't bother checking if there was a restyle
expected for the current frame or not.
Since we normally wait for 5 frames anyway before checking that there have been
no restyles, failing to count the number of frames and waiting only 4 frames is
not a problem. However, if a new test were added that just copied this code and
only waited one frame, it might fail to test what it intended. So, to avoid
possible future bugs and in order to be more consistent with tests that do
expect restyles, this patch replaces a number of uses animation.ready with
waitForAnimationReadyToRestyle.
MozReview-Commit-ID: 7qBmobTKolh
--HG--
extra : rebase_source : baa272102fed7a66cc4fc89f6d63ba0333087a2d
And replace tweakExpectedRestyleCount with the function.
MozReview-Commit-ID: 96jC9looyZq
--HG--
extra : rebase_source : 7dae8b258b874a9b366767a6e49de83bf2caccc9
The crash reporter symbol files are the easiest cross-platform way to
find static initializers. While some types of static initializers (e.g.
__attribute__(constructor) functions) don't appear there in a notable
way, the static initializers we do care the most about for tracking do
(static initializers from C++ globals). As a matter of fact, there is
only a difference of 2 compared to the currently reported count of 125
on a linux64 build, so this is a good enough approximation. And allows
us to easily track the count on Android, OSX and Windows builds, which
we currently don't do.
The tricky part is that the symbol files are in
dist/crashreporter-symbols/$lib/$fileid/$lib.sym, and $fileid is hard to
figure out. There is a `fileid` tool in testing/tools, but it is a
target binary, meaning it's not available on cross builds (OSX,
Android).
So the simplest is just to gather the data while creating the symbol
files, which unfortunately requires to go through some hoops to make it
happen for just the files we care about.
--HG--
extra : rebase_source : 458fed1ffd6f9294eefef61f10ff7a284af0d986
This was changing the project from "main" -> ("main",) which was causing the DocUp
task to upload to urls like:
"('main',)/62.0/_sources/..."
MozReview-Commit-ID: 1bL9nqiAEFE
--HG--
extra : rebase_source : 8f4148dd003dfcfb4c0ba513e4fa7e2ca540dce3
When we traverse up a shadow DOM we pass in null as an indicator to
move upwards. We now check that it is really an element and if not
assume that it is null and move up the tree
MozReview-Commit-ID: AK9eOLFDAgB
--HG--
extra : rebase_source : c748d0fd22d29286f40b78b8790f4a339dfd4299
The current element finding and interaction code expects the shadow DOM
to act like a frame when it comes to keeping references to elements found
or not found on the document. This expectation is not correct for the way
shadow DOM works in reality.
MozReview-Commit-ID: JFWvlbEylj4
--HG--
extra : rebase_source : de99b01e33cd7c54de5d7c2c0396704e78878eef
When evaluating if an object can be null, which would mean that we would
not be able to pass through IPC as, the commandId could not be added to null.
This patch makes sure that we can still send commands via IPC if the object is
evaluated to null.
MozReview-Commit-ID: Fl3Ionj08Sk
--HG--
extra : rebase_source : 33d015ac235ee74e903e13e234c55fda298f8e66
elementsFromPoint will return the top level element of a shadow DOM
and not the elements within. If we are on the top level document we
need to make sure to use the correct rootNode.
MozReview-Commit-ID: ATvCidAFEeM
--HG--
extra : rebase_source : c6c8e20745a64b19cc0d1784044efe4fed4af9bf
There are some places where we have a thing which may not even be a node, and
we end up hardcoding the value of DOCUMENT_NODE there, because
"foo.nodeType == foo.DOCUMENT_NODE" will test true if foo is not a node: both
sides will be undefined.
Execute a single write transaction per chunk, rather than a larger read/write transaction.
Also removes useless statement scopers when we create a single-use statement.
MozReview-Commit-ID: 3G37d55Z1dV
--HG--
extra : rebase_source : ed9132563b06dac471ccb0b28554fe30a3d75560
This was simply an oversight in the implementation of Bug 1464128.
What's happening is that `set_config` in `moz.configure` is not
unconditional, and NIGHTLY_BUILD is set in local builds and in B and N
builds in automation, so there was no test of the other case, which
promptly fails. This re-uses a pattern successful in mobile/android
for setting defines.
MozReview-Commit-ID: 4zL4hVsqE3Q
--HG--
extra : rebase_source : f6033ed9be0afde7d1a5502bf69234247c95b8ba
