When SplitNode returns nullptr, GetAsText causes crash. So we should check
error before casting by GetAsText.
MozReview-Commit-ID: 8E1OPSRZ2x5
--HG--
extra : rebase_source : 48a067bd080e7a68e9d469c07d3b744508dae91f
As explained in the extended comment in this patch, for Servo we want to post
restyles when creating new animations so that we run a second animation
restyle and incorporate the result of new animations into style immediately.
(Gecko does everything in the one restyle, and although this causes other bugs
related to triggering transitions, at least it means it does not require
restyles to be posted here).
It turns out that we normally end up posting a restyle anyway in
CSSAnimation::SetAnimationIndex. Bug 1332958 was supposed to drop that but it
never landed.
However, CSSAnimation::SetAnimationIndex only posts a restyle when there is
a change to the animation index. It turns out that, by chance, there normally
*is* a change to a CSSAnimation's animation index when it is created. Initially
it takes its animation index from Animation::sNextAnimationIndex which is
incremented each time it is assigned to an animation.
If the first Animation we create for a given content process is a CSSAnimation
then sNextAnimationIndex will be zero and so we will initially assign an
animation index of zero. If that CSS animation is also the first in the list
of animations in animation-name, when we call SetAnimationIndex we will pass
zero as the index to use, and when we go to update the animation index we will
detect that there is no change, and will NOT post an animation restyle.
As a result the target element's style will NOT reflect the animated style.
To fix this we need to ensure that *new* CSS animations trigger a restyle.
For *changes* to animations, the corresponding calls to SetKeyframes and
SetSpecifiedTiming post restyles so the behavior should be correct in those
cases.
For *removed* animations I observed that in at least some cases we successfully
post a restyle. However, this appeared to be as much by chance as anything so
this patch also posts a restyle for removed animations. (Note that the
EffectCompositor will ignore redundant restyle requests so this is ok.)
This patch deliberately does not expose Animation::PostUpdate and call that
because the code introduced here is intended to be temporary. Long-term we
should remove the Gecko style backend and allow the calls to PlayFromStyle,
PauseFromStyle, CancelFromStyle etc. to post restyles just like calls to Play,
Pause, and Cancel do. At that point this code can also be removed.
MozReview-Commit-ID: 4c3vJdLBqeY
--HG--
extra : rebase_source : 684cb483562709161b2d5635e173e55319509a70
The != tests actually pass, but this is hard to express in the failures.list
pattern matching, so we just mark them all as random.
MozReview-Commit-ID: 2qr8a1isSEV
--HG--
extra : rebase_source : 14d2756ea044065579e1b3937d8417a3ef004317
There are currently some corner cases where channels that are eventually
loaded into documents (mainly <img src="data:image/svg+xml,") can inherit
expanded principals from a caller. Since documents aren't allowed to have
expanded principals, this causes crashes.
This patch is a short term workaround for the issue, until we have a longer
term solution that prevents the channels from inheriting the expanded
principals to begin with.
MozReview-Commit-ID: JwqqtVynLjj
--HG--
extra : rebase_source : 23199517414428924e9c78629ac794b54bd23c52