Bug 202472 - Drop-shadow filter repaints incorrectly when using CSS transitions
Summary: Drop-shadow filter repaints incorrectly when using CSS transitions
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Animations (show other bugs)
Version: Other
Hardware: Mac macOS 10.14
: P2 Major
Assignee: Nobody
URL: https://jsfiddle.net/vnqpx2rL/1/
Keywords: InRadar
: 236974 (view as bug list)
Depends on:
Reported: 2019-10-02 08:56 PDT by Viktor Zozuliak
Modified: 2022-03-16 07:22 PDT (History)
13 users (show)

See Also:

unexpected shadow trail (12.79 KB, image/png)
2019-10-02 08:56 PDT, Viktor Zozuliak
no flags Details
simple drop-shadow repaint test (489 bytes, text/html)
2022-03-03 21:34 PST, Simon Fraser (smfr)
no flags Details
drop-shadow repaint with descendants (1.04 KB, text/html)
2022-03-03 21:35 PST, Simon Fraser (smfr)
no flags Details
drop-shadow transition (550 bytes, text/html)
2022-03-04 13:37 PST, Simon Fraser (smfr)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Viktor Zozuliak 2019-10-02 08:56:39 PDT
Created attachment 380028 [details]
unexpected shadow trail

Safari 13.0.1

Given element with:
- box-shadow filter
- transition of CSS property which changes position (e.g. margin-left)

Steps to reproduce:
- change element's CSS property to which transition is applied

- observe trail left by element's shadow during transition (look at screenshot attached)

- no shadow trail

- https://jsfiddle.net/vnqpx2rL/1/

- apply "transform: translateZ(0)" CSS to element (hacky, non obvious)
Comment 1 Radar WebKit Bug Importer 2019-10-02 13:17:32 PDT
Comment 2 Drew McMurry 2020-02-11 14:19:02 PST
This issue can similarly be seen here.

Comment 3 Antoine Quint 2020-11-03 01:57:20 PST
Moving to Layout and Rendering component as this seems to be a repaint issue.
Comment 4 Simon Fraser (smfr) 2022-03-03 21:30:55 PST
The issue here is that we don't take drop-shadow into account as visual overflow (like we do, say, for box-shadow).

That would be easy to do for a single element, but drop-shadow is more complex, because it contributes visual overflow to all the descendant boxes as well. This more like how outlines need to impact repaint for descendants.
Comment 5 Simon Fraser (smfr) 2022-03-03 21:34:53 PST
Created attachment 453810 [details]
simple drop-shadow repaint test
Comment 6 Simon Fraser (smfr) 2022-03-03 21:35:19 PST
Created attachment 453811 [details]
drop-shadow repaint with descendants
Comment 7 Simon Fraser (smfr) 2022-03-04 08:33:48 PST
*** Bug 207586 has been marked as a duplicate of this bug. ***
Comment 8 Simon Fraser (smfr) 2022-03-04 13:37:38 PST
I'll use this bug to track the transition-specific issues with drop-shadow.
Comment 9 Simon Fraser (smfr) 2022-03-04 13:37:53 PST
Created attachment 453868 [details]
drop-shadow transition
Comment 10 Simon Fraser (smfr) 2022-03-04 13:39:21 PST
Two issues that I see:
1. After a drop-shadow transition, the element remains composited forever.
2. We seem to be confused about CA rendering the drop-shadow vs. painting it; at the end of the transition, a layout update rejiggers the composited layer such that the drop-shadow paints inside it.
Comment 11 Simon Fraser (smfr) 2022-03-04 13:43:08 PST
*** Bug 236974 has been marked as a duplicate of this bug. ***
Comment 12 Bramus 2022-03-16 03:05:12 PDT
Got a similar report on my blog, pointing to https://codepen.io/badcat/pen/LYzzWvy as a demo. Adding the translateZ(0) hack fixes it.

The user submitted the issue via Feedback Assistant, with id FB9819385. Perhaps these cases could be linked?
Comment 13 kelter (badcat) 2022-03-16 07:22:24 PDT
Fwiw, in the instance of my this only appears to happen on hover and when the viewport area (of parent element) is less than the dropshadow. https://codepen.io/badcat/pen/LYzzWvy

In the MDN example, the failed dropshadow occurs within an iframe. https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/drop-shadow()