In some cases there are imported tests where the same test is compared against
two reference pages, once as == and once as !=. Webrender is currently failing
the == tests but not the != tests. However there is no way to annotate this
precisely in the failures.list file, so we had previously marked the tests
as random-if. This patch modifies the import-tests.py to recognize a ref:<file>
argument in failures.list to match the reference file as well, and uses it to
clarify the webrender reftest expectations.
MozReview-Commit-ID: 6nAXoCQDreI
--HG--
extra : rebase_source : 93633ed6f62ccfb4b28ebed34943781350c4c831
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
--HG--
extra : rebase_source : ceb95bdce1042cbfc16751d6d023fc6feee5845e
This new change hint doesn't influence layout so that it can be regarded
as nsChangeHint_Hints_CanIgnoreIfNotVisible. Note that if visibility changed
from collapse or to collapse, we set NS_STYLE_HINT_REFLOW separetely.
MozReview-Commit-ID: AirDWeBYVKG
--HG--
extra : rebase_source : 1cd03a78a522b1a6965ba73ebf002ddacb0ab4f2
This replaces reftest's homebrewed chunking algorithm with the one that
all the other test harnesses use in manifestparser.
For now Android will continue to use the reftest based algorithm.
MozReview-Commit-ID: AfUBmQpx3Zz
--HG--
extra : rebase_source : cb513d1b3a54ddeb95ce5861d858aad4492de2a6
Instead of parsing the manifests and running the tests all in one go, this will
spawn an extra Firefox instance at the beginning that does nothing but parse the
manifest and dump them to a file.
This will allow the python harness to load and manipulate the test objects, before
sending them back to the JS harness as a list of tests to run. The main motivation
for this change is to implement run-by-manifest, a mode where we restart the
browser in between every test manifest. But there are other benefits as well, like
sharing the chunking logic used by other harnesses and the ability for the python
harness to stuff arbitrary metadata into the test objects.
For now, Android will continue to parse the manifests and run the tests all in one
go. Converting Android to this new mechanism will be left to a follow-up bug.
MozReview-Commit-ID: AfUBmQpx3Zz
--HG--
extra : rebase_source : 955966c07bb650946c7c0e5706856f028335e850
Currently manifest parsing happens within the StartTests method. This method is
already quite large, and this commit series about to make the logic around
gathering tests a lot more complicated.
This commit pulls the manifest parsing out into a new 'ReadTests' method which
is responsible for retrieving the list of tests (however that may be) and then
calling StartTests.
MozReview-Commit-ID: 6ijOqhNaig
--HG--
extra : rebase_source : 16d4e2debcbe95765c4355b9964f62c7e7a417f1
This is a simple refactor of manifest.jsm.
We'd like to access the test objects from the parsed manifest in python. This
will allow us implement things like runByManifest (to improve intermittent
stability), share the chunking logic used by other harnesses, and much more.
To do this, we need to JSON serialize all of the test objects and dump them
to a file. The python side can then load the file, make modifications, and
send it back to the JS side to run.
The problem is that we turn the test urls into nsIURI objects as soon as they
are parsed, which isn't JSON serializable. This commit is a simple refactor to
delay this from happening. Instead, we will create the urls in reftest.jsm,
after the modified test objects have been loaded from python. This step will
be implemented by the next commit.
MozReview-Commit-ID: 6ijOqhNaig
--HG--
extra : rebase_source : 06acb038a4d3e35b3a4158b81b361a9a0ae54337
All the arrays we're switching to ranged loops can't mutate during the loop
since are locals or not referenced from other places.
MozReview-Commit-ID: C2N73HMMeNW
--HG--
extra : rebase_source : 428dd2805cb58b3ac5fcddb549b960f72615bf6f
Just something I noticed while sneaking into bug 1435634.
RemoveElement returns whether the element was actually removed, so no need to
use Contains to bail out.
MozReview-Commit-ID: FryHBV66yRV
Bug 1427292 broke display: contents on non-special MathML elements.
Just for reference, I've manually audited calls to nsIFrame::GetContent() in
MathML and turns out that MathML is pretty well-behaved in that sense (it
inspects the frame tree, then gets the content), so it should work fine with
display: contents / ShadowDOM.
Only exception to that is[1], but that one seems harmless.
[1]: https://searchfox.org/mozilla-central/rev/eeb7190f9ad6f1a846cd6df09986325b3f2c3117/layout/mathml/nsMathMLmactionFrame.cpp#301
So we can enable or implement when the CSSWG pleases.
MozReview-Commit-ID: 8N6kiGyjE4i
--HG--
extra : rebase_source : a80197e39b20bc6ab385a3d0b90628bc4ad81d92
We'll stop dispatching keypress events on web contents for conforming to spec of
UI Events. Some existing tests assumes that keypress events are fired even
when non-printable keys are pressed.
This patch makes them check the pref,
"dom.keyboardevent.keypress.dispatch_non_printable_keys_only_system_group_in_content"
and only listen to keydown event instead of keypress even if the pref is true
and expected key event is not a printable key press.
MozReview-Commit-ID: 6bKoK7dsB0l
--HG--
extra : rebase_source : b3705b0814d5690e00208d0d3315f09f886c6f26
It's the last thing we check before looking into the array, modulo other two
tags, so there should be no need for something more fancy.
MozReview-Commit-ID: 4Wi1fe7jBlN
--HG--
extra : rebase_source : c13394a0b057e28cd922f1d15cb8b149a4204292
This is a new issue that gets linted with flake8 3.5.0. Basically you should
never use a blank except: statement.
This will catch all exceptions, including KeyboardInterrupt and SystemExit
(which is likely not intended). If a catch all is needed, use
`except: Exception`. If you *really* mean to also catch KeyboardInterrupt et
al, use `except: BaseException`.
Of course, being specific is often better than a catch all.
MozReview-Commit-ID: FKx80MLO4RN
--HG--
extra : rebase_source : 7c74a7d0d81f2c984b47aff3a0ee3448b791177b
I left some IgnoredErrorResults for now where people warn on failure. We could
consider adding a WarnOnError() thing or something.
MozReview-Commit-ID: L5ttZ9CGKg0
Dorel Luca
Gurzau Raul
Kartikaya Gupta
Andrew McCreight
Alexis Beingessner
Brindusan Cristian
Narcis Beleuzu
Hiroyuki Ikezoe
Andrew Halberstadt
Noemi Erli
Emilio Cobos Álvarez
Gerald Squelart
Masayuki Nakano
Andreea Pavel
Brad Werth
Brian Birtles
Boris Zbarsky
Sebastian Hengst
Florian Quèze