This implements the changes to the specified behavior from the following
changeset:
a9ba51338e
It also updates test expectations based on the tests updated in part 1 of this
patch series.
MozReview-Commit-ID: HyJC8tHXLYc
--HG--
extra : rebase_source : 6d0f5eb03a2bb4c3938d79dfae7ee433d33fd2b1
Based on the following changes to the specification:
a9ba51338e
MozReview-Commit-ID: zSKTr4T8BM
--HG--
extra : rebase_source : 26747443cfb359e53349b7977bae79e8f928e78a
If we create an animate SVG along with its parent, in rare cases,
the animation does not start in the first frame, i.e, it's the frame
that the animated element and its parent element are created. In such
cases, restyle for the animation is not observed in the first frame.
To avoid it, we need to create parent element in the first place,
then, append an animated element into the parent in the next frame.
MozReview-Commit-ID: 3GPDxX4cmkQ
--HG--
extra : rebase_source : 5cfa60deb3661df443ffd07c8e39d50752ab47f8
We should just check the from value of the new transition instead of
checking computed style. That's because the new transition moves back
to the original position while we are waiting for the callback of paints.
For example, on Android, thumbnail creation is sometimes processed between
paints and callbacks. (Gecko's main loop spins after paints process, most
of callbacks are processed there)
MozReview-Commit-ID: JyJsmEuIiKn
--HG--
extra : rebase_source : 80d1f6500ae2ba93ea034c622e59576ef60d09bb
This patch was generated by the command:
find * -type f -exec sed -i -f ../mozpropsub {} \;
in the root of the repository, with the file ../mozpropsub containing:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
s/\<MozPaddingEnd\>/paddingInlineEnd/g
s/\<MozPaddingStart\>/paddingInlineStart/g
s/\<MozMarginEnd\>/marginInlineEnd/g
s/\<MozMarginStart\>/marginInlineStart/g
s/\<MozBorderEnd\>/borderInlineEnd/g
s/\<MozBorderEndColor\>/borderInlineEndColor/g
s/\<MozBorderEndStyle\>/borderInlineEndStyle/g
s/\<MozBorderEndWidth\>/borderInlineEndWidth/g
s/\<MozBorderStart\>/borderInlineStart/g
s/\<MozBorderStartColor\>/borderInlineStartColor/g
s/\<MozBorderStartStyle\>/borderInlineStartStyle/g
s/\<MozBorderStartWidth\>/borderInlineStartWidth/g
The diffs for the following files:
layout/style/nsCSSPropAliasList.h
layout/style/test/property_database.js
layout/style/test/test_value_computation.html
were then manually removed from the patch.
MozReview-Commit-ID: 8fbYnlZcn9U
This adds a few basic tests for expectations of when we do and don't
restyle, construct frames, and reflow in response to changes of media
queries. They don't give us a lot of coverage, but often the tiny bits
of coverage at the beginning are the most useful.
In general, I'd like us to have more tests for specific optimizations,
i.e., for specific things that we expect not to happen in certain cases.
The elementsRestyled, framesConstructed, and framesReflowed getters on
DOMWindowUtils are a good way to make such measurements for a number of
things in layout; that's why I added them.
(Inspired a bit by bug 1259641.)
MozReview-Commit-ID: JFtlPO1eyoD
This adds support for #rgba and #rrggbbaa colors to CSS. This feature
is specified in https://drafts.csswg.org/css-color-4/#hex-notation .
This adds new types to nsCSSValue so that we can serialize the syntax
that was specified, as we do for other distinctions in how colors are
specified.
It does not change the behavior of the hashless color quirk, which
continues to support only 3 and 6 digit colors as specified in
https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk (step 4).
This changes property_database.js to remove various uses of 4 and 8
digit colors as invalid values. It then adds them in slightly fewer
places as valid values, but more thoroughly testing both initial and
non-initial values on 'color'.
It marks two canvas tests explicitly testing this feature as no longer
known to fail by removing their .ini files.
Finally, it adjusts the web platform test testing the hashless color
quirk to no longer treat 4 and 8 digit colors with hashes as invalid
values. Removing the relevant test items seems like the right thing
since they're in a section where 3 and 6 digit colors were skipped but
other lengths were tested. Modifying this imported test is OK since:
<jgraham> dbaron: Commit the change you want to m-c, it is
(semi-)automatically upstreamed every so often (typically
about once a week)
MozReview-Commit-ID: IFq4HxaRkil
I'm acting under the assumption that this is what's closest to what the
code does now, except without asserting in ~ErrorResult. It also seems
closest to what event listeners will do, both based on examining code
(EventListenerManager::HandleEventSubType, which I'm hoping is the right
code to look at, calls StealNSResult, and then stores it in a member
that's ignored by most callers) and based on testing (for both click
events, and for media query listeners with this patch, the exception
gets reported to the console as an unhandled exception). That said, I'm
not particularly well versed in the current error handling rules so I
may well be off here.
This code should presumably go away when we change this code to use
EventListeners in bug 1265622, so I don't think there's any spec that
covers this.
Without the patch, the mochitest hits the fatal assertion (after
reporting hitting the expected uncaught exception). With the
patch the test passes. (Tested locally.)
MozReview-Commit-ID: 5kxp6jzGzX8
--HG--
extra : transplant_source : n%B4%AE%99D%FB%B9NM%C0%A2%F0%D4%B7%8C%E7%DE4E%60
We use _pretty_path when specifying the targets of generated files, so
we need to use _pretty_path for the inputs as well. Otherwise make won't
know that they refer to the same file, and result in "No rule to make
target" errors.
MozReview-Commit-ID: JTdLFbkX1J0
This adds testing for transitions on background-position-x/y, and makes sure we
no longer call check_distance for background-position, because
background-position is now a shorthand and no longer has its own distance
computation.
MozReview-Commit-ID: 82KVruCghGe
--HG--
extra : rebase_source : c7c85abc9bb7ff1987d7372635c0a9702715b761
This adds testing for transitions on background-position-x/y, and makes sure we
no longer call check_distance for background-position, because
background-position is now a shorthand and no longer has its own distance
computation.
MozReview-Commit-ID: 82KVruCghGe
--HG--
extra : rebase_source : 65e52287c141044df8ae490d461ebef3e8d403ec
Astley Chen
Xidorn Quan
Brian Birtles
Xidorn Quan
Hiroyuki Ikezoe
Kyle Zentner
Mats Palmgren
Matt Woodrow
Mike Shal
Ethan Lin
Thomas Wisniewski
Edgar Chen
Daniel Holbert
Phil Ringnalda
Daisuke Akatsuka
CJKu
L. David Baron
Ryan VanderMeulen
Carsten "Tomcat" Book
Jared Wein
Mantaroh Yoshinaga
Markus Stange
Wes Kocher