300845 2025-10-15 16:22:26 -0700 [css-anchor-position-1] display: block to none transition doesn't work with anchor positioning 2025-11-04 02:17:18 -0800 1 1 1 Unclassified WebKit CSS WebKit Nightly Build Unspecified Unspecified RESOLVED DUPLICATE 301056 InRadar P2 Normal --- 1 kiet.ho kiet.ho kiet.ho koivisto webkit-bug-importer oldest_to_newest 2151458 0 kiet.ho 2025-10-15 16:22:26 -0700 rdar://160639948 2151459 1 kiet.ho 2025-10-15 16:25:39 -0700 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. 2151460 2 477096 kiet.ho 2025-10-15 16:25:59 -0700 Created attachment 477096 Reduced testcase 2156217 3 kiet.ho 2025-11-04 02:17:18 -0800 Dupe of 301056 *** This bug has been marked as a duplicate of bug 301056 *** 477096 2025-10-15 16:25:59 -0700 2025-10-15 16:25:59 -0700 Reduced testcase anchor-function-transition.html text/html 730 kiet.ho PCEtLSByZGFyOi8vMTYwNjM5OTQ4IChbcm9vdF0gW0FuY2hvciBQb3NpdGlvbmluZ10gSjcxNS8y NUUxMTY6IFRleHQgb3ZlcmxhcHMgd2hlbiBzd2l0Y2hpbmcgYmV0d2VlbiBuZXN0ZWQgc3VibWVu dXMpIC0tPgo8IS0tIFNvdXJjZTogaHR0cHM6Ly9jb2RlcGVuLmlvL21pY2hlbGxlYmFya2VyL3Bl bi9xQkdFVm92IC0tPgoKPHN0eWxlPgoubWVudSB7Cgl3aWR0aDogY2FsYygxMDAlIC8gMyk7Cglh bmNob3ItbmFtZTogLS1hbmNob3I7CiAgICAgICAgYm9yZGVyOiAxcHggc29saWQgYmxhY2s7Cn0K Ci5zdWJtZW51IHsKICAgICAgICBkaXNwbGF5OiBub25lOwogICAgICAgIHBvc2l0aW9uOiBhYnNv bHV0ZTsKCWxlZnQ6IGFuY2hvcigtLWFuY2hvciByaWdodCk7CgoJdHJhbnNpdGlvbjogZGlzcGxh eSAzcyBhbGxvdy1kaXNjcmV0ZTsKfQo8L3N0eWxlPgoKPGRpdiBjbGFzcz0ibWVudSI+Cgk8YnV0 dG9uIG9uY2xpY2s9InRyYW5zaXRpb24oKSI+CgkJT3BlbgoJPC9idXR0b24+Cgo8L2Rpdj4KCjxk aXYgY2xhc3M9InN1Ym1lbnUiIGlkPSJzdWJtZW51Ij4KCUNvbnRlbnQKPC9kaXY+CgoKPHNjcmlw dD4KZnVuY3Rpb24gdHJhbnNpdGlvbigpIHsKICBpZiAoc3VibWVudS5zdHlsZS5kaXNwbGF5ID09 PSAiYmxvY2siKQogICAgc3VibWVudS5zdHlsZS5kaXNwbGF5ID0gIm5vbmUiOwogIGVsc2UKICAg IHN1Ym1lbnUuc3R5bGUuZGlzcGxheSA9ICJibG9jayI7Cn0KPC9zY3JpcHQ+Cg==