As required by the recent spec change:
d696468777
MozReview-Commit-ID: Ev6kUk1uLAY
--HG--
extra : rebase_source : 70f8ca3143a8b3bb4e03016b9989925d5a328049
We don't however, use arrow syntax for local functions that act as class
constructors since they don't want the lexical this that arrow functions use.
MozReview-Commit-ID: FuVhHIBFZrE
--HG--
extra : rebase_source : 919bbe7a6f6fc42281411ad4058540f233a3e010
This tests the behavior clarified in the following spec changeset:
d696468777
MozReview-Commit-ID: 3hS7rHcTpUn
--HG--
extra : rebase_source : 13941772212d169824d3058a131067ca0823d2ca
This naming is recommended by [1] and from a random sampling of tests in
web-platform-tests it seems like most test don't use this, only tests that are
split over multiple files.
This "processing a keyframes argument" section is quite large so I intend to
split the tests up into a number of files to cover:
* Tests for property access
* Tests for easing
* Tests for offset
* Tests for composite
* Tests for equivalent forms
[1] http://web-platform-tests.org/writing-tests/general-guidelines.html#file-paths-and-names
MozReview-Commit-ID: JW2m50UnsKv
--HG--
rename : testing/web-platform/tests/web-animations/interfaces/KeyframeEffect/processing-a-keyframes-argument.html => testing/web-platform/tests/web-animations/interfaces/KeyframeEffect/processing-a-keyframes-argument-001.html
extra : rebase_source : fafe135996b11661385b0f28a82abc9b11c77c25
This seems to be standard JS style recently (as used in prettier etc.): Use
spaces to separate the { and } from the properties (but not for arrays).
MozReview-Commit-ID: FRkFRwwcJJh
--HG--
extra : rebase_source : f45fbc371bc23b542032612bcf4578ee4de9f98e
* We should refer to reading or accessing properties, as opposed to
"considering" them.
* We should use "property-indexed" consistently.
MozReview-Commit-ID: ItCE4g8LmOC
--HG--
extra : rebase_source : 8656dc185f6e6e820a283a725fd4217336b06712
There is a test that assumes that an offset specified on a property-indexed
keyframe is applied to all generated keyframes but that behavior is not (yet)
specified.
This behavior will be specified in [1] but until that happens it seems invalid
to test for it. Furthermore, when that is specified we will need much more
thorough tests than this one.
[1] https://github.com/w3c/web-animations/issues/148
MozReview-Commit-ID: HUUw88dg2P7
--HG--
extra : rebase_source : 5e38d8f0fb01b3ecf7339ca1be0e31c775bf4b21
But only in a couple of places where it makes the test more readable.
MozReview-Commit-ID: 6zVJ6h7Zb3k
--HG--
extra : rebase_source : 8ec4e7957cfccb4b60b97032a1a12fa12d9ff589
for...of is generally preferred over forEach since it is a little easier to read
and allows using 'break' and 'continue'. Furthermore it is supported in all
major browsers. (It also makes wrapping one of the long lines in this file
easier.)
MozReview-Commit-ID: 1BuoW0QSxaG
--HG--
extra : rebase_source : 4c0e04720cda5ecb60a276ac52c595cba693aa16
Gradually we plan to move all these tests to ES6 (or at least the subset
supported by all UAs that are likely to implement this spec) so while we are
touching this file we update a few uses of 'var' to let/const.
MozReview-Commit-ID: 45OJyXmUzKu
--HG--
extra : rebase_source : a14138a9ffddd8a89da0635e316f918297010529
KeyframeEffectReadOnly may disappear (see [1]) and is only needed for CSS
Animations and CSS Transitions so in that sense KeyframeEffect is more basic
(despite being a subclass of KeyframeEffectReadOnly) so we should prefer it to
KeyframeEffectReadOnly.
Furthermore, as the comment at the start of the file suggests, we should
consistently use the same method for testing these procedures. We currently use
the KeyframeEffect constructor because it is more direct and basic.
[1] https://github.com/w3c/web-animations/issues/185
MozReview-Commit-ID: LBrlfzyn2Ch
--HG--
extra : rebase_source : 358c60c89c70d642cb5c193a1bdff4e5991aac54
And also drop the slightly misleading and redundant comment about the procedure
that this test covers (it covers *both* the "process a keyframes argument"
procedure and the "process a keyframe-like object" subprocedure).
MozReview-Commit-ID: 9lzx4rCj20o
--HG--
extra : rebase_source : 64c429d8dfceb7e518cac1418cd6c6ea6de16eaf
Bug 1382564 made the `mach artifact toolchain` invocations from
mozharness use the MOZ_TOOLCHAINS environment variable when it's set by
taskcluster through the decision task, so that toolchain dependencies
from the task graph are used, but the mozharness code is still skipping
mach artifact toolchain when MOZ_TOOLCHAINS is set but there is no
tooltool manifest set. Most jobs today still have a tooltool manifest
set, but jobs shouldn't need a dummy tooltool manifest to use toolchain
dependencies automatically.
--HG--
extra : rebase_source : 0437a8f3d43a83ffe32c4192f86ee9a621977e3e
We need mozharness configurations and mozconfigs for rusttests. We are
explicitly not doing Windows debug configurations currently because of
peculiar link errors in such configurations.
This patch:
- removes the obsolete mozilla-aurora l10n-bumper config.
- adds both central and beta format desktop bumper configs to jamun for testing.
- updates the central and beta configs to add desktop.
- updates the script to support the desktop configs.
We now support an `ignore_config` which acts like the `ignore-platforms` attribute.
MozReview-Commit-ID: KGwo0bRibw4
--HG--
extra : rebase_source : 1014c8d46104fc3b05586aa64f207cf38f37f98f
Set the idle preference to be the current time, so that idle-daily won't kick in for 24 hours.
MozReview-Commit-ID: 6OJCSm8RaeZ
--HG--
extra : rebase_source : 71217263ddd5b9299e8463254f48ad2d9918b8a2
With newer Selenium atoms which do not conflate attributes and
properties, the retrieval via getElementAttribute will fail. By
retrieving it directly as property will fix it.
MozReview-Commit-ID: CFy3JZDeUWq
--HG--
extra : rebase_source : ed3a358f52b7cd54f3c5dda037fddaa93173e3b6
Brian Birtles
Andreas Tolfsen
Wes Kocher
John Dai
Mike Hommey
Nathan Froyd
Aki Sasaki
Marina Samuel
Sebastian Hengst
Andrew Halberstadt
Mark Banner
Henrik Skupin
Markus Stange
Thomas Wisniewski
Ryan VanderMeulen
Geoff Brown