The test assumes "en" is always an accepted language, it's not correct.
This assumption isn't what is being tested here anyway.
We should set language preference at the beginning before testing to avoid
irrelevant failure.
Differential Revision: https://phabricator.services.mozilla.com/D32628
--HG--
extra : moz-landing-system : lando
We can run /debug mochitests against geckoview for the cost of another dozen
or so test annotations. Both /opt and /debug mochitests are nearly worthy of
tier 1, but still waiting for bug 1534732.
Differential Revision: https://phabricator.services.mozilla.com/D30931
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
This also adopts the resolution from [1] while at it, making letter-spacing
compute to a length, serializing 0 to normal rather than keeping normal in the
computed value, which matches every other engine.
This removes the SMIL tests for percentages from letter-spacing since
letter-spacing does in fact not support percentages, so they were passing just
by chance.
[1]: https://github.com/w3c/csswg-drafts/issues/1484
Differential Revision: https://phabricator.services.mozilla.com/D21850
--HG--
extra : moz-landing-system : lando
As it turns out we need this to avoid losing precision both during painting and
during serialization.
This patch also changes to serialize `context-value` if it's the computed value.
I could keep the previous behavior, but it makes no sense to serialize the
initial value. We're the only ones to support this value anyway, and I couldn't
find a definition or spec for this.
Also update tests and expectations for:
* New unexpected passes.
* Always serializing the unit in getComputedStyle.
* Calc and interpolation support.
Chrome also always serializes the unit in getComputedStyle, so I'm pretty sure
this is compatible with them. Chrome is inconsistent and keeps numbers in
specified style, but that's inconsistent with itself and with other quirky
lengths, so I updated the tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D21819
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
This is probably the last thing we will ship since it needs the most spec work.
MozReview-Commit-ID: LLmDBLCsCBJ
--HG--
extra : rebase_source : c06752c9201a9ede87e1ac200ab12577bf784ce6
Changing to Stylo for animation of color with currentColor. Stylo uses
a different distance metric for numeric colors to currentColor. The
result is that a different pacing is used in the fill case.
MozReview-Commit-ID: 5x8c3IF5owV
--HG--
extra : rebase_source : fd1656237fd5df03481e410bae29167df2317536
Changing to Stylo for animation of color with currentColor. Stylo uses
a different distance metric for numeric colors to currentColor. The
result is that a different pacing is used in the fill case.
MozReview-Commit-ID: 5x8c3IF5owV
--HG--
extra : rebase_source : 422dfa69644052a4c9cbfb2355a105c8e5c2b50c
Disable failing SMIL tests for lighting-color with currentcolor until
StyleComplexColor is extended to support addition.
MozReview-Commit-ID: 6tbDYPFI9ey
--HG--
extra : rebase_source : a8f1e363bd37c40ae2e48ef682a005aafaa27fe5
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
This matches the behavior of Chrome at least, and should reduce compatibility
risk when we remove accessKey support in the next patch in this series by
ensuring that specifications such as begin="3s; accessKey(s)" will continue to
run the animation.
MozReview-Commit-ID: E6sh48yrYSm
--HG--
extra : rebase_source : 1ad85b55acfd226c660386ff579811ed2e70f260
Normally when we interpolate values for CSS properties we convert empty values
(such as the empty "from" value created for a by-animation) to a suitable zero
value. However, when we use discrete interpolation that step never occurs and in
some rare cases that means we end up setting the empty value on the target
attribute directly which will have an incorrect result (e.g. setting "" for the
height property will have no effect, whereas setting "0px" will).
This patch makes us perform the empty value to zero value conversion when
performing discrete animation.
Unfortunately it is not possible to test this behavior with shorthands since
there are currently no shorthand properties that are additive.
MozReview-Commit-ID: JFT1tis1RAR
--HG--
extra : rebase_source : cc444b6d4d5571c8ab231d88c4d349ea0713baaa
Currently, Gecko converts lengths in stroke-* properties to numbers when
creating animation values and hence the result of animation is always a unitless
value for these properties.
Servo, on the other hand, converts lengths for these properties to numbers
during interpolation and hence sometimes the result of animation is a unitless
value, and other times (such as when skipping interpolation) it is not.
Other browsers produce lengths with px units and ultimately we should align
with that behavior. As a result, this patch updates various SMIL mochitests to:
* Expect animation values with px unit
* Compare values by stripping px units as a temporary measure until we
correctly serialize these values with px (bug 1379908).
MozReview-Commit-ID: IsT26DKkgiP
--HG--
extra : rebase_source : 8d8dee6ad53d29801096d3affe996e4df1a9388c
In SMIL if a discrete calcMode is used, the keyTimes attribute may be used to
specify the times at which the various animation values are used, overriding the
regular 50% flip behavior (see nsSMILAnimationFunction::ScaleSimpleProgress).
However, this behavior is only applied when the calcMode is known to be
discrete. If the author specifies calcMode="linear" but
attributeType="stroke-linecap" then SMIL should fall back to discrete calcMode
including applying the special keyTimes behavior.
For the Servo backend, Servo_AnimationValues_Interpolate does not return an
error for discretely animated properties so SMIL does not recognize when we fall
back to discrete calcMode. This patch adds a check before performing
interpolation that tests if the property is a discretely interpolable one and,
if it is, returns an error so that we run SMIL's special discrete calcMode
handling.
MozReview-Commit-ID: FOp8XcNbvdu
--HG--
extra : rebase_source : 57ddb333855de111aa585fe894e99937681e5cd2
The spec says,
font weight: interpolated via discrete steps (multiples of 100). The
interpolation happens in real number space and is converted to an integer by
rounding to the nearest multiple of 100, with values halfway between
multiples of 100 rounded towards positive infinity.[1]
However, our implementation pre-dates this spec text (bug 528234 landed Nov 2009
whereas the spec was updated in Mar 2012[2]).
This patch rounds the result by simply adding 50 to the result before we floor
it (which is good enough in this case because we don't need to worry about
negative values).
It also slightly simplifies the logic by re-using Clamp from MathAlgorithms.h.
[1] https://drafts.csswg.org/css-transitions/#animtype-font-weight
[2] 00c6286109
MozReview-Commit-ID: BjCg7MG70hW
--HG--
extra : rebase_source : 879ea18d7d1a49ff425d6e467081983a130a65e3
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
longsonr
Victor Porof
Mark Banner
violet
Cosmin Sabou
Geoff Brown
Brian Grinstead
Emilio Cobos Álvarez
Josef Citrine
Ciure Andrei
Julian Descottes
Brian Birtles
Dan Glastonbury
Brindusan Cristian
Tom Ritter
Andrew Halberstadt
Mantaroh Yoshinaga
Xidorn Quan
Aryeh Gregor
Florian Quèze
Astley Chen