In the case where values in CSS rules changed directly by CSSOM, the old
value in the CSS rule block is immediately replaced by the new one. So if
the element, which is applied to the CSS rule, has running animations, the
new value is used during cascading process in animation-only restyle. Thus
in a subsequent normal restyle, we can't tell whether the value in the CSS
rule has changed or not. As a result, transitions may not be triggered
(bug 1393323) and CSS animations may not be cancelled if the updated
animation-name is 'none' (this bug).
For the latter case of CSS animations where animation-name has been updated to
'none', this patch introduces a workaround whereby we trigger an update of
running animations whenever the traversal is triggered by changes to CSS rules
and we have existing CSS animations.
change-animation-name-to-none-in-rule.html fails without servo #18214, succeeds
with this patch. Other two tests succeed regardless of the PR.
MozReview-Commit-ID: BrZgTNk9w41
--HG--
extra : rebase_source : 7a55f54a0f94c8db02639f9d8c89f785b3a17a1b
Current stylo uses LengthOrPercentage::Calc for interpolation between length and
percentage, but neither gecko nor stylo will support the calc value for
stroke-dasharray. (bug 1258270 / bug 1386967)
So current stylo will not animate this types.
In this bug, we make stroke-dasharray interpolation between length and
percentage as discrete type until we properly support calc() for stroke-dasharray
(bug 1258270 / bug 1386967), as a result, rendering results of this type
matches with gecko.
MozReview-Commit-ID: FBuJM254ZdS
--HG--
extra : rebase_source : 634435089e3a72c03d62a7e4d51195e03c68d5b6
Using namespace id fixes this issue because in Gecko, the pref of MathML
(as well as SVG) works in the way that we choose a different namespace
id (the disabled id) for the elements. Those ids are mapped to the same
namespace atom as normal ids, which means if we use the atom, we would
treat the elements like normal mathml elements.
MozReview-Commit-ID: 9YBBokbP04M
--HG--
extra : rebase_source : 397f09db41a22bfa34e4abe26ad10027dab83d0d
This was already marked fuzzy but now the difference between the test and
reference images is even more pronounced. Technically this might still be fuzzable
because the thickness of the text (which is what is different) is not what the
test is testing for. But if we fuzz it the fuzz numbers would be so high that
legitimate failures might get fuzzed as well, so it's better to just mark it
failing for now and deal with it later.
MozReview-Commit-ID: 3Wt32XB1TWG
--HG--
extra : rebase_source : 5310a5b2deb187dcf0e4d3bc009bfae6abd1ef24
When a reframe happens on the parent of a pseudo element which has animations,
we need to grab style for the pseudo element that includes the animations'
style and also *replace* old style context (that does not include animations'
style) with it. Otherwise, we will use the old style context that has *no*
animations style, as a result, we will see a flicker right after the reframe.
Two reftests in this patch fail without this fix. One is for CSS transitions,
the other one is for CSS animations.
MozReview-Commit-ID: 6pCdnQ1DGUY
When display style is changed from 'none' to other in animation-only restyle
we need to resolve descendant elements' style that were in the display:none
subtree.
Three possible ways to resolve the descendant elements' style;
1) Traversing unstyled elements in animation-only restyle
We can't simply traverse unstyled elements in the animation-only restyle
since when we decided to traverse the unstyled elements we don't know yet
the elements will be initially styled or are in display:none subtree. It
will result that the new elements are styled in animation-only restyle,
it's undesirable.
2) Creating a SequentialTask and resolve the descendants' style with
ServoStyleSet::StyleNewSubtree()
We can't resolve the descendants' styles with ServoStyleSet::StyleNewSubtree()
in SequentialTask since at the moment we are still in servo traversal (i.e.
sInServoTraversal is true). That means AutoSetInServoTraversal fails
in PrepareAndTraverseSubtree().
3) Creating a SequentialTask and set restyle subtree hint and defer descendants'
restyle in a subsequent normal traversal
Note that, when we process throttled animations flush, we don't process
normal traversal so the descendants will not be traversed until normal
restyle happens but it will not be a big problem since it's really rare
that user clicks display animation element just at the right moment when
display property changes from none to other. Also, if it will be really
a problem, we should process *only* transform animations on the compositor,
it's ideally right thing to do. Display property never runs on the
compositor.
This patch takes the third approach.
MozReview-Commit-ID: Krxa3kkdIq4
--HG--
extra : rebase_source : 33e9db953f21168c76716329568191625bd15896
After bug 1356141, the setup of animation-only dirty bit should have matched
to normal dirty bit's one (Though they don't match in post traversal due to
throttled animation flush). An unset_animation_only_dirty_descendants call
removed in this patch cleared dirty bits which are needed for post traversal if
there is a second animation-only traversal and if there is no need to restyle
for the second animation-only traversal.
The reftest in this patch fails without either this fix or the fix for bug
1367975.
See [Gecko bug 1384435 comment 12](https://bugzilla.mozilla.org/show_bug.cgi?id=1384435#c12)
for more detail what's going on at that time.
MozReview-Commit-ID: Dw24Vgoabmd
--HG--
extra : rebase_source : 7f64dc16b03b0c0a32ac5dfeb4f8561c900d461e
With this patch, we now have an automated test to verify if a transition
is run properly on a visited link. Note that the test aims to verify
the behavior in Stylo should match that in Gecko. Due to Bug 868975, we
haven't supported transitioning on visited styles yet, so the test should
be put in our own repo for now. This test can be tweaked and put into
web-platform repo once we resolve Bug 868975.
MozReview-Commit-ID: Ci1cERXkIUK
--HG--
extra : rebase_source : 7feb1229bc2dc430bc2a1e40be40047049469fbd
This doesn't actually implement style context reparenting in the style set yet; that part is next.
There is one behavior difference being introduced here compared to Gecko: we
don't reparent the first block piece of an {ib} (block-inside-inline) split
whose first inline piece is being reparented. This is actually a correctness
fix. In this testcase:
<style>
#target { color: green; }
#target::first-line { color: red; }
</style>
<div id="target">
<span>
<div>This should be green</div>
</span>
</div>
Gecko makes the text red, while every other browser makes it green.
We're preserving Gecko's behavior for out-of-flows in first-line so far, but
arguably it's wrong per spec and doesn't match other browsers either. We can
look into changing it later.
MozReview-Commit-ID: 5eC6G449Mlh
--HG--
extra : rebase_source : 8c333a0afe96c68a4e3b6aeca1b742ef8d5edd3b
Since we make "font-variant-alternates" animatable,
should remove test fail annotation from reftest.list.
MozReview-Commit-ID: ChdeSvUbTBh
--HG--
extra : rebase_source : fac9fb01a60c684d7169866964621f431b3508e3
This reftest fails without the first patch on stylo.
MozReview-Commit-ID: E5pBzBw9x8B
--HG--
extra : rebase_source : 4fe2a99bfed76d1b5fb320ef6a4f2b39ee5f5f2c
This is a quick work around for not blocking the progress of Bug 1380133.
We should definely investigate the real root cause sooner than later.
MozReview-Commit-ID: 8X1FH6f2GyN
In case of pseudo elements ElementHasAnimations is set on the parent element.
updating-animation-on-pseudo-element.html fails without this patch, succeeds
with this patch.
MozReview-Commit-ID: HJaX7m8nV96
--HG--
extra : rebase_source : 15466f065d852ebc5fefd5d305639ba366a221f6
Both Servo and Gecko store the specified value of the image-orientation
property as a single-precision float, but Gecko does the conversion to radians
and the computation to identify which quarter-turn the angle is closest to
using doubles.
We add Angle::radians64 to perform the conversion to radians using doubles,
just as Gecko does, and then update image_orientation to perform the
computation the same exact way Gecko does in
nsStyleImageOrientation::CreateAsAngleAndFlip. This lets the previously failing
reftests pass.
We also update Gecko_SetImageOrientation to take an orientation directly
instead of an angle (otherwise we'd be doing the which-quarter-turn-is-closest
computation twice).
Finally this lets us re-enable the reftests for image-orientation previously
marked as fails-if(styloVsGecko||stylo).
MozReview-Commit-ID: 2zMMzQlsYEC
--HG--
extra : rebase_source : 99ed023e940193d4ad735a9ee27e45929a1efda1
Previously we just took the input angle mod 2π, which will leave negative input
angles as negative. By checking if the input mod 2π is negative and if so
adding 2π and then taking that mod 2π again we can ensure that we end up with a
an angle in the range [0, 2π].
We only do this if the result of the initial mod is negative because this adds
rounding error that is enough to mess up whether 135 is determined to be closer
to 90 or 180, for example.
We add a test for this as well.
Also fix property_database.js to account for this (we assert that -90deg should
compute to the same value as the initial value, but it should actually compute
to 270deg).
MozReview-Commit-ID: Faf0f7wIEg3
--HG--
extra : rebase_source : 6b2d15f90e541fcb8b6083e15772eee514603e57
Previously, in paginated mode, all reflows were dirty reflows, since
tables do not split outside of printing, and prior to the primary patch
in bug 1308876, all reflows during printing are dirty reflows. (The
isPaginated test here is actually for real pages, not fragmentation in
general. However, the use here is appropriate for the meaning of
whether it's possible for the table to fragment.)
The fact that all reflows were dirty reflows meant that the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always cleared immediately
before reflow in ReflowInput::InitResizeFlags (which might also have set
the flag on *ancestors*). This meant that, prior to the primary patch
in bug 1308876, the initial value of needToInitiateSpecialReflow that
was initialized from the presence of the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always false. This patch
preserves that initialization in the presence of the change in the
primary patch in bug 1308876.
This caused a failure in a single test in our test suite, and in a
rather complicated way. The test was
layout/base/crashtests/470851-1.xhtml, in which there was both a
difference in assertion count (due to the bogus assertion "data loss -
incomplete row needed more height than available, on top of page" in
nsTableRowGroupFrame::SplitRowGroup, whose companion assertion "data
loss - complete row needed more height than available, on top of page"
is already just an NS_WARNING) that caused a test failure, and a
difference in layout (the test split across 3 pages rather than 2) that
did not cause a test failure.
This patch fixes the difference in layout. The immediate cause of the
layout difference was that a cell (the second outermost) on the second
page had a height, computed in CalcUnpaginatedBSize, that was large
enough to cause it to need to continue onto the third page. This height
came (via nsTableRowFrame::GetUnpaginatedBSize) from the
UnpaginatedHeightProperty stored on the first-in-flow of its row, on the
first page, stored by CacheRowBSizesForPrinting called in
nsTableRowGroupFrame::ReflowChildren during the reflow of its row group
on the first page, in a special height reflow initiated during the
second-pass constrained-height reflow of the table (still,
second-outermost) on the first page, due to the change being fixed in
this patch.
MozReview-Commit-ID: 3E84VwdXuPs
The primary patch in this bug causes fewer dirty reflows, which leads to lines
being out-of-date for the reason described in the comment. This causes
incorrect layout of some references sections on wikipedia, for which a
simplified testcase is included.
This bug was not caught by anything in our test suite, but I noticed it
while browsing wikipedia (since I use a build that has my patches in it
for my regular browsing).
MozReview-Commit-ID: 4hTQpGS2pZH
This fixes a failure in layout/reftests/bugs/467084-1.html, triggered by
the primary patch in bug 1308876, on Android only (or on all platforms
if I add 'html { overflow: hidden }').
I confirmed locally (on Linux) that, without this patch, both
layout/reftests/bugs/467084-1.html with 'html { overflow: hidden }', and
the reftest added here, fail, but that with the patch they both pass.
MozReview-Commit-ID: 3SjTlnBngBV
This fixes an incremental layout bug, where the number of times we
reflow the frame affects its layout. This is because we make the
decisions about the vertical scrollbar before the horizontal scrollbar
(and, when making the decision, adjust mHelper.mScrollPort for the size
of the scrollbar). Thus, in order to avoid a situation where reflowing
the scrollframe once leads us to have no vertical scrollbar, but
reflowing it a second time leads us to add that scrollbar, we need to
retest for the need for a vertical scrollbar after we add the horizontal
one.
(It's possible there are some other missing cases here, but this is the
one that (a) already existed in the code and (b) is needed to fix the
reftest failure on Windows that I got on bug 1308876, in
layout/reftests/text-overflow/xulscroll.html .
The reftest here shows the bug even without bug 1308876 (though I
confirmed that only by loading the test and reference in a nightly
build, not in the reftest harness). I did test that, in combination
with bug 1308876, the test fails without the patch and passes with the
patch.
MozReview-Commit-ID: LhMi7LbmB6J