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
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 : eeba14d732077ef2e412f4caca852de6b6b85f55
We resolve pending animations when painting has finished in
nsDisplayList::PaintRoot. However, in the process we can trigger nested calls to
PaintFrame (e.g. due to use of -moz-element). In that case, we shouldn't resolve
pending animations until we complete the widget transaction.
This patch adds a check that we're in a widget transaction before we resolve
pending animations.
After starting layer animations we set the same start time on content
animations but we don't apply it until the next tick (see bug 1112480 for
background). However, in some circumstances, we can end up creating layer
animations again within the same refresh driver tick. In this case, we should
initialize the animations with the same start time as we previously used.
This patch exposes the pending start time set on content animations so that,
if set, we can use it when building layer animations.
It feels safer to use a function with a new name, rather than just changing the
behaviour of the existing function.
For most of these cases the PL_DHashTableLookup() result was checked with
PL_DHASH_ENTRY_IS_{FREE,BUSY} so the conversion was easy. A few of them
preceded that check with a useless null check, but the intent of these was
still easy to determine.
I'll do the trickier ones in subsequent patches.
--HG--
extra : rebase_source : ab37a7a30be563861ded8631771181aacf054fd4
We do not want to traverse inside native anonymous elements, but we
should still be able to skip over generated content, to avoid getting
stuck on such images.
The caret movement code already handles unselectable text frames if we
happen to land in the middle of one in nsTextFrame::PeekOffsetCharacter/Word.
However, when performing frame traversal to find the next frame to jump
to, we don't remember if we skipped over an unselectable frame, which causes
us to jump one offset too much when the caret is on the boundary of
selectable and unselectable content. The test cases demonstrate the
scenario. Note that an <img alt=foo> is implemented by adding a
generated content to the inline frame representing it, so as far as
the caret movement code is concerned, both test cases are treated similarly.
Note that we need to do this only when moving the selection, and not
when extending it. We are adding an aExtend argument to
nsPeekOffsetStruct's constructor in order to be able to special case
that.
We do not want to traverse inside native anonymous elements, but we
should still be able to skip over generated content, to avoid getting
stuck on such images.
The caret movement code already handles unselectable text frames if we
happen to land in the middle of one in nsTextFrame::PeekOffsetCharacter/Word.
However, when performing frame traversal to find the next frame to jump
to, we don't remember if we skipped over an unselectable frame, which causes
us to jump one offset too much when the caret is on the boundary of
selectable and unselectable content. The test cases demonstrate the
scenario. Note that an <img alt=foo> is implemented by adding a
generated content to the inline frame representing it, so as far as
the caret movement code is concerned, both test cases are treated similarly.
Note that we need to do this only when moving the selection, and not
when extending it. We are adding an aExtend argument to
nsPeekOffsetStruct's constructor in order to be able to special case
that.
Sometimes, in very specific cases, the visible region gets simplified to one rect and is thus much bigger than the draw region. This becomes a problem if we decide to pull an opaque background color from a lower layer so that we are opaque. In which case we draw the background color over the whole visible region. But we use the draw region to determine if we can place items below this layer, so that background color could cover them incorrectly.
The content inside an editable region is either editable itself, or
is inside a contenteditable="false" subtree. In the first case,
it should not be focusable since it is editable. In the second
case, it should not be focusable since the entire non-editable
region is treated as a special single entity for the purposes of
selection and caret movement, and having something focusable in
the middle of such a subtree breaks that model.
The content inside an editable region is either editable itself, or
is inside a contenteditable="false" subtree. In the first case,
it should not be focusable since it is editable. In the second
case, it should not be focusable since the entire non-editable
region is treated as a special single entity for the purposes of
selection and caret movement, and having something focusable in
the middle of such a subtree breaks that model.
