When verifying error messages, the second parameter of Assert.throws has
to be a regular expression.
MozReview-Commit-ID: LJ6Iif8ORTs
--HG--
extra : rebase_source : 0cbe9f31880df44f9c822d8410ab4571281c17ef
We missed adding it for the implementation on bug 1387094.
DONTBUILD
MozReview-Commit-ID: E717NEO7o2U
--HG--
extra : rebase_source : facb28d006e514bff6796f8c0e085c73f313d0ce
The Marionette server now returns a JSON containing the cause of shutdown which isn't included in previous Firefoxen. We needed to test this JSON in the quit and restart methods in the python client.
MozReview-Commit-ID: 8uL9tbNszcm
--HG--
extra : rebase_source : 7f01fe55444b034a5f07e42acac0224a981be881
There were two issues with the previous implementation:
* Domain cookies were created as host only cookies (due to lack of
leading '.' characters)
* The cookie domain included in the Marionette request was completely
ignored, which always resulted in host-only cookies
MozReview-Commit-ID: 2JLQ3vwNMrb
--HG--
extra : rebase_source : c72ba077ef1b1a1f308e4c9a1d2093c18f7483ce
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
