Bug 219729 – filter won't apply to child elements while they are animating

• Component: Animations
• Status: NEW

[Jamie Kyle]

Created attachment 415839 [details]
A demo of the bug

Online Demo: https://jsbin.com/gucaweyica/1/edit?html,output (code is attached)

    <div style="filter: url(#filter)">
      <div style="animation: ...">
    </div>

When a parent element has a filter, and the child element has an (active) animation, the child element will render without the filter applied.

When the element stops animating, the filter will apply to the child element.

[Smoley]

Thanks for filing, I can reproduce this on Safari 13.1.3 and STP 117.

[Radar WebKit Bug Importer]

<rdar://problem/72366401>

[Maurici Abad]

I'm also encountering with this error

[Evelyn Hathaway]

This issue still persists in Safari 18.5 and TP 225.

Note that it's not all animations. For instance, if you modify the original demo to be a `background-color` animation, it will animate with the blur just fine. It seems to be specifically related to certain properties that create a new stacking context. In the demo, this is caused by animating a `transform`, but I've found that `scale`, `rotate`, `translate`, `opacity`, `filter`, and `backdrop-filter` all cause the same issue as well.

Similar to the `animation`, triggering a `transition` with one of those properties will prevent the filters from applying for the duration of the transition, and setting `will-change` to one will prevent the filter from applying indefinitely — no actual animation is needed. Interestingly, actually using one of the stacking context properties mentioned does not prevent the filter from being applied, it's only when they are used in `animation:`, `transition:`, or `will-change:`.

Additionally, `animation-fill-mode: forwards` prevents the filter from applying even after the animation is complete, just like the underlying `will-change`.

And even when they are not visually applied, Safari's performance grinds to a halt if the filter is computationally intensive. I am not a Safari performance expert, but compositor trace items take longer, and scrolling through a page with a lot of complex SVG dilation filters will prevent even unfiltered portions of the page to fail to paint unless you wait, so it seems almost if this compute is still being done, just not displayed.

---

Reporter's online demo modified to have will-change and no animations, which still prevents the blur from applying to the child: https://jsbin.com/siqizotova/edit?html,output

[Evelyn Hathaway]

Interestingly, the bug doesn't occur when animating a custom property, so adding a custom property as a proxy may be a workaround for those experiencing the issue.

Reporter's online demo modified to animate a custom property in the keyframes which visually animates as the reporter intended: https://jsbin.com/tuwonegaya/1/edit?html,output