RESOLVED FIXED 205925
[Web Animations] Stop creating CSS Animations for <noscript> elements
https://bugs.webkit.org/show_bug.cgi?id=205925
Summary [Web Animations] Stop creating CSS Animations for <noscript> elements
Antoine Quint
Reported 2020-01-08 06:57:53 PST
[Web Animations] Stop creating CSS Animations for <noscript> elements
Attachments
Patch (7.54 KB, patch)
2020-01-08 07:02 PST, Antoine Quint
koivisto: review+
Antoine Quint
Comment 1 2020-01-08 07:02:15 PST
Antoine Quint
Comment 2 2020-01-08 07:02:20 PST
Antti Koivisto
Comment 3 2020-01-08 07:41:23 PST
Comment on attachment 387103 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=387103&action=review > Source/WebCore/ChangeLog:16 > + It makes no sense to create CSS Animations for a <noscript> element and it has the side effect of potential crashes. > + Indeed, AnimationTimeline::updateCSSAnimationsForElement() may be called without a currentStyle and so we never have > + a list of previously-applied animations to compare to the list of animations in afterChangeStyle. So on each call we > + end up creating a new CSSAnimation and the previous animation for the same name is never explicitly removed from the > + effect stack and is eventually destroyed and the WeakPtr for it in the stack ends up being null, which would cause a > + crash under KeyframeEffectStack::ensureEffectsAreSorted(). You'll should add some other defense against this in animation code too as this patch likely doesn't cover all the paths where this can happen. > Source/WebCore/html/HTMLElement.cpp:736 > -bool HTMLElement::rendererIsNeeded(const RenderStyle& style) > +bool HTMLElement::rendererIsEverNeeded() You can also switch HTMLInputElement::rendererIsNeeded to rendererIsEverNeeded, maybe others. Please check, they can probably all be used to get this crash.
Antti Koivisto
Comment 4 2020-01-08 08:04:24 PST
In fact most rendererIsNeeded functions can be turned into rendererIsEverNeeded. Doesn't need to be done in this patch though.
Antoine Quint
Comment 5 2020-01-08 08:27:49 PST
(In reply to Antti Koivisto from comment #3) > Comment on attachment 387103 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=387103&action=review > > > Source/WebCore/ChangeLog:16 > > + It makes no sense to create CSS Animations for a <noscript> element and it has the side effect of potential crashes. > > + Indeed, AnimationTimeline::updateCSSAnimationsForElement() may be called without a currentStyle and so we never have > > + a list of previously-applied animations to compare to the list of animations in afterChangeStyle. So on each call we > > + end up creating a new CSSAnimation and the previous animation for the same name is never explicitly removed from the > > + effect stack and is eventually destroyed and the WeakPtr for it in the stack ends up being null, which would cause a > > + crash under KeyframeEffectStack::ensureEffectsAreSorted(). > > You'll should add some other defense against this in animation code too as > this patch likely doesn't cover all the paths where this can happen. It's more than a defense that is needed, the problem is that `AnimationTimeline` doesn't know to expect several CSS Animations with the same animation-name. I will address this as part of a different bug as soon as possible. I raised https://bugs.webkit.org/show_bug.cgi?id=205928. > > Source/WebCore/html/HTMLElement.cpp:736 > > -bool HTMLElement::rendererIsNeeded(const RenderStyle& style) > > +bool HTMLElement::rendererIsEverNeeded() > > You can also switch HTMLInputElement::rendererIsNeeded to > rendererIsEverNeeded, maybe others. Please check, they can probably all be > used to get this crash. I will add more rendererIsNeeded overrides in a followup, I raised
Antoine Quint
Comment 6 2020-01-08 08:28:20 PST
(In reply to Antoine Quint from comment #5) > I will add more rendererIsNeeded overrides in a followup, I raisedhttps://bugs.webkit.org/show_bug.cgi?id=205929
Antoine Quint
Comment 7 2020-01-08 08:30:49 PST
Note You need to log in before you can comment on or make changes to this bug.