Because of bug 1341294, we sometimes receive other MozAfterPaint event that
what we are not waiting for.
MozReview-Commit-ID: 5ltrPv1igs7
--HG--
extra : rebase_source : faf8f760800be4e8dc4bf01fe66381c132910e87
We create empty rectangle (zero-height or zero-width) frame for element which
has no content inside it, e.g. '<p></p>'. And nsRect.Intersects returns false
if either of the rectangles are empty, so if we check
!transformedRect.Intersects(scrollableRect) and transformedRect is empty, we
will end up returning true from IsFrameScrolledOutOfView even though the point
represented by the empty transformedRect might be inside the
scrollableRect.
The reftest causes timeout without this fix since the animation never updates
after the initial paint.
MozReview-Commit-ID: FymFJfjxyGc
--HG--
extra : rebase_source : 6ebcd354be300b779e84f013fa4db7d13e36c551
We had previously started running some tests in layers-free mode
already, either by setting the default-preferences on the folder to
turn on layers-free, or by duplicating an individual reftest annotation
so that it ran in both layers-full and layers-free mode. This patch
removes these changes since layers-free is now the default and we don't
need to run layers-full at all.
MozReview-Commit-ID: JJwB9iO5clU
--HG--
extra : rebase_source : ea20545945b825d7ff829526d4d263850e6b5b7f
This patch:
- adds fails-if annotations for all the reftests that were consistently failing
with layers-free turned on.
- removes fails-if or reduces the range on fuzzy-if annotations for all
the reftests that were producing UNEXPECTED-PASS results with
layers-free turned on.
- adds skip-if, random-if, or fuzzy-if annotations to the reftests that
were intermittently failing due to timeout, obvious incorrectness, or
slight pixel differences, respectively.
MozReview-Commit-ID: A0Aknn6rnjj
--HG--
extra : rebase_source : 420d9cf43f23a5d654fa36eec69138937d13c173
Skip tests that are expected to fail in both Stylo and Gecko modes. They would unexpectedly "pass" in styloVsGecko mode when comparing the two failures, which is not a useful result.
MozReview-Commit-ID: 3mOpjU225Q1
--HG--
extra : rebase_source : 22bb5d4e3c5138ef832995eaf5716824f4707ffe
extra : source : d40fb20c9a49d0797c0eeae613a04912b12a28f7
Skip tests that are expected to fail in both Stylo and Gecko modes. They would unexpectedly "pass" in styloVsGecko mode when comparing the two failures, which is not a useful result.
MozReview-Commit-ID: 3mOpjU225Q1
--HG--
extra : rebase_source : 0c307639c3626af3b6b43e05d3ee73d08b3f47ce
This was a test case for bug 1379203 (Google Inbox issue), but to pass this test
also needs the fix in this series to cancel animations when changing
animation-name to 'none' in the specified CSS rule.
Actually the fix in this series also fixes the Google Inbox issue so that this
test can pass without the fix for the Google Inbox issue. But even so without
the fix for bug 1379203, the style data for the first div element in this test
is cached and the second div element uses the cached data.
MozReview-Commit-ID: GfKSDfTZef4
--HG--
extra : rebase_source : caad72ed69e4ebeec8b8cad25949ea69e3bb652e
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
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
This reftest fails without the first patch on stylo.
MozReview-Commit-ID: E5pBzBw9x8B
--HG--
extra : rebase_source : 4fe2a99bfed76d1b5fb320ef6a4f2b39ee5f5f2c
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
reftest-print mode for animations does not work well yet.
We will handle it in bug 1374154.
MozReview-Commit-ID: GUGSEE4VJwQ
--HG--
extra : rebase_source : fd8ee42fd26fc6caaaded7bbaed69188f6005896
This is because in original gecko, canvas background color will merge to
painted layer with other display items. When advanced canvas background
color is enabled, the "other display items" won't be merged with canvas
background color. Which means the layers that are generated by those
display items may not be opaque. So set fails-if to those tests.
MozReview-Commit-ID: 1WbMU8pGtTC
--HG--
extra : rebase_source : c7bc417cde65ece8589d733a63d4a6e1a161d1fe
Hiroyuki Ikezoe
Ian Moody
Kartikaya Gupta
Sebastian Hengst
Ethan Lin
Chris Peterson
Phil Ringnalda
Daisuke Akatsuka
Tobias Schneider
Morris Tseng
Shing Lyu
Manish Goregaokar
Boris Zbarsky
Florian Quèze
Cameron McCormack
Jeff Muizelaar