I confirmed that we're actually using this codepath by manually testing
<input type=color>: it works with the patch, but if I comment out the
call to nsHTMLCSSStyleSheet::PseudoElementRulesMatching from
nsStyleSet::RuleNodeWithReplacement, then the color swatch breaks, which
proves that we're depending on the code.
I think I included this in the queue because it is needed for patch 22,
although I've forgotten the full reasoning.
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
This is needed for patch 17, which removes restyling phases, so that
when the transition manager posts a restyle to undo the covering done by
the cover rule, that restyle doesn't get consumed by an inner frame.
This is needed to prevent these reftests from failing:
layout/reftests/svg/smil/smil-transitions-interaction-1a.svg
layout/reftests/svg/smil/smil-transitions-interaction-1b.svg
layout/reftests/svg/smil/smil-transitions-interaction-2a.svg
layout/reftests/svg/smil/smil-transitions-interaction-2b.svg
layout/reftests/svg/smil/smil-transitions-interaction-4a.svg
layout/reftests/svg/smil/smil-transitions-interaction-4b.svg
The mIsCSS path fixes the a tests, and the !mIsCSS path fixes the b tests.
This is because this patch series changes the way in which transitions
interact with other types of animations to depend on those animations
being flushed in the animation-only style flush. (The relevant call is
added in patch 6, though we don't really depend on it until patch 17.)
This depends on bug 1087536 patch 3, which posts animation restyles
using the eRestyle_CSSTransitions and eRestyle_CSSAnimations hints.
This is used by patch 6.
Due to the caret images changed, we need to change this test
accordingly.
It's sufficient to perform hit tests only targeting the left edge of the
left tilted caret and the right edge of the right tilted caret. It also
reduces the running time of the tests.
It's sad that we cannot retrieve the CSS style of the carets from ua.css
directly. We need to copy them to the test file by hand.
The first failure in rc1 was:
TEST-UNEXPECTED-FAIL | testAxisLocking | PaintExpecter - blockUtilClear timeout
and the first failure in rc2 (API9) or rc3 (API11) was:
TEST-UNEXPECTED-FAIL | testPanCorrectness | PaintExpecter - blockUtilClear timeout
This makes UpdateOverflow hint handling (which definitely did previously
need CHILDREN_AND_PARENT_CHANGED) and handling of related hints (which I
believe never actually needed CHILDREN_AND_PARENT_CHANGED) use the
CHILDREN_CHANGED hint in the overflow changed tracker, since use of
CHILDREN_AND_PARENT_CHANGED is no longer needed following the
introduction of the UpdateParentOverflow hint in patch 2.
This cleans up after bug 984226, which introduced
CHILDREN_AND_PARENT_CHANGED to deal with the facts that:
(1) most properties whose changes yield UpdateOverflow style hints
imply that an element's overflow area may have changed, and
propagation to ancestors can stop without updating the element's
parent if the element's own overflow area didn't change.
(2) a few properties whose changes yield UpdateOverflow style hints
actually don't change the overflow area of the element on which the
property changed, but instead change that element's overflow area
on the element's parent.
Having two separate hints means that we don't have to do the extra work
of always updating the parent's overflow area (when the child's overflow
area didn't actually change) for the properties in category (1), and we
don't have to do extra work of updating the element's own overflow area
for properties in category (2).
When choosing a painted layer for the event region item we must report the bounds of the hit regions as the bounds so that we don't fall through to the bottom most painted layer.
I kept all the existing PL_DHashTableAdd() calls fallible, in order to be
conservative, except for the ones in nsAtomTable.cpp which already were
followed immediately by an abort on failure.
--HG--
extra : rebase_source : 526d96ab65e4d7d71197b90d086d19fbdd79b7b5
David Anderson
Kartikaya Gupta
L. David Baron
Carsten "Tomcat" Book
Ting-Yu Lin
Morris Tseng
Timothy Nikkel
Nicholas Nethercote
Ryan VanderMeulen
David Burns
Jonathan Kew
Simon Montagu
Jeremy Chen
Jeremy Chen
Kaustabh Datta Choudhury
Frédéric Wang
Seth Fowler