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
Currently if we have transition-property: 'all' and trigger a transition
on the 'color' property we will end up generating a transition on
-webkit-text-fill-color even if that property is disabled.
However, when we later call StyleAnimationValue::ToValue() in
nsTransitionManager::UpdateTransitions() to see if there are any transitions we
need to cancel, the comparison for currentValue != anim->ToValue() will pass
(since, as of the first patch in this patch series, ToValue() returns a null
value) so we end up cancelling the transition as soon as we create it).
Nevertheless, we will still trigger the warning introduced in the first patch
in this series when we call ToValue().
This patch stops us from creating transitions in the first place (and hence
triggering the warning). It also removes the code that suppresses transition
events for transitions on disabled properties since we should no longer be
generating such transitions in the first place (unless the pref is switched
while the transition is in motion which is probably not worth worrying about).
Note that we only test if the property is enabled for all content. This is
consistent with what we do throughout animation code including the existing
code in nsTransitionManager which iterates through shorthand sub-properties
using CSSPROPS_FOR_SHORTHAND_SUBPROPERTIES with the flag
nsCSSProps::eEnabledForAllContent.
The test case in this patch doesn't actually fail without this change, all it
does it trigger the warning in StyleAnimationValue::ToValue() introduced
in the first patch in this series. It's still a useful regression test however,
particularly if we later upgrade the warning in StyleAnimationValue::ToValue()
to a fatal assertion.
MozReview-Commit-ID: H9swDKLyiOf
This patch backs out changeset range 1f1884449dd4:0b5ed5e4a395 (all of the patches for bug 1208344) -- i.e. it backs out our support for "-webkit-box-orient". This patch also adds "fails" annotations to two reftests that depend on that feature, to reflect reality that these tests are now expected to fail (for the moment).
MozReview-Commit-ID: F8zGGg8R0Rn
