RESOLVED DUPLICATE of bug 301056300845
[css-anchor-position-1] display: block to none transition doesn't work with anchor positioning
https://bugs.webkit.org/show_bug.cgi?id=300845
Summary [css-anchor-position-1] display: block to none transition doesn't work with a...
Kiet Ho
Reported 2025-10-15 16:22:26 PDT
Attachments
Reduced testcase (730 bytes, text/html)
2025-10-15 16:25 PDT, Kiet Ho
no flags
Kiet Ho
Comment 1 2025-10-15 16:25:39 PDT
See reduced testcase. On the first click, "Content" transitions from display: none to block, and it displays at the correct location. On the second click, it transitions from display: block to none. However, when the transition is running, the content jumps to a different position, which it shouldn't. This is because left: anchor(...) fails to resolve, and it fallbacks to left: auto. The culprit seems to be around StyleTreeResolver.cpp:793: auto applyAnimations = [&]() -> std::pair<std::unique_ptr<RenderStyle>, OptionSet<AnimationImpact>> { if (hasUnresolvedAnchorPosition) return { WTFMove(resolvedStyle.style), OptionSet<AnimationImpact> { } }; When an anchor-positioned element transitions from display: block to none: * On the first style resolution, resolvedStyle.style->display() == none, hasUnresolvedAnchorPosition is true because anchor positioned elements are only resolved after the second resolution. Hence, we return resolvedStyle.style as the animation style, which has display: none. RenderTreeUpdater will then tear down the renderer because display: none * On the second style resolution: ** AnchorPositionEvaluator::updateAnchorPositioningStatesAfterInterleavedLayout runs to match anchors for anchor-positioned element. However, since the anchor-positioned's renderer doesn't exist (previously torn down), it couldn't match any anchors. ** AnchorPositionEvaluator::evaluate is called to evaluate the anchor function, but since no anchor matches are recorded, the function can't be resolved ** When TreeResolver::createAnimatedElementUpdate runs, the transition is applied. Transition from display: block to none results in block until the end of the transition, when it switches to none. So the new style will have display: block ** RenderTreeUpdater creates a new renderer because there was no renderer (previously torn down), and display: block The result: * We needlessly tear down and create new renderers * More importantly, on the second style resolution, we can't resolve anchor functions. Therefore when the transition is running, the position of the anchor-positioned element is as if the anchor functions can't be resolved The second point results in the content jumping when the transition from display: block to none runs.
Kiet Ho
Comment 2 2025-10-15 16:25:59 PDT
Created attachment 477096 [details] Reduced testcase
Kiet Ho
Comment 3 2025-11-04 02:17:18 PST
Dupe of 301056 *** This bug has been marked as a duplicate of bug 301056 ***
Note You need to log in before you can comment on or make changes to this bug.