Bug 254575

Summary: [css-lists] `content: counter()` does not update visually if `position: absolute` is set
Product: WebKit Reporter: Antoine Quint <graouts>
Component: CSSAssignee: zalan <zalan>
Status: RESOLVED FIXED    
Severity: Normal CC: bfulgham, changseok, dino, esprehn+autocc, ews-watchlist, glenn, graouts, koivisto, kondapallykalyan, pdr, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
URL: https://codepen.io/jh3y/pen/vYyxoPr
Attachments:
Description Flags
Test
none
Reduced test
none
[fast-cq]Patch none

Description Antoine Quint 2023-03-28 00:46:53 PDT
This twitter thread reports an issue with animating an <integer> custom property and codepen that reduces it somewhat: https://codepen.io/jh3y/pen/vYyxoPr. We have testing coverage for <integer> animation so I expect it's not strictly an animation issue, it could be something related to `counter-reset` or `content: counter(ms)` which are also used in the demo.
Comment 1 Antoine Quint 2023-03-28 04:22:56 PDT
Inspecting the page, I think there's no trouble actually animating the --milliseconds value since I see it changing every time I call getComputedStyle($0).getPropertyValue("--milliseconds"). Additionally, the first time I open Web Inspector after launching Safari and loading the demo, I see the counter value change to a different value each time. I expect this is indeed an issue with `counter()`.
Comment 2 Antoine Quint 2023-03-28 04:30:34 PDT
Created attachment 465629 [details]
Test
Comment 3 Antoine Quint 2023-03-28 05:30:32 PDT
When we hit RenderTreeUpdater::GeneratedContent::updatePseudoElement() the call to Style::determineChange() returns Style::Change::None and we fail to call updateStyleForContentRenderers() as required. This is not related to animations at all, this is also an issue when changing the style through other means.
Comment 4 Antoine Quint 2023-03-28 06:08:03 PDT
Actually, the issue goes away if we remove the `position: absolute` style in `.counter:after`.
Comment 5 Antoine Quint 2023-03-28 06:10:17 PDT
Created attachment 465630 [details]
Reduced test
Comment 6 Antoine Quint 2023-03-28 07:07:33 PDT
Using the reduction, I can notice a difference under RenderBlockFlow::layoutModernLines() where in the good case (no position style set) the first call to modernLineLayout() returns false and where in the bad case (`position: absolute` is set) it returns true. Cc'd Alan who might know more as a layout expert.
Comment 7 zalan 2023-03-28 17:39:12 PDT
Created attachment 465649 [details]
[fast-cq]Patch
Comment 8 EWS 2023-03-29 05:30:45 PDT
Committed 262269@main (1b539330d2ad): <https://commits.webkit.org/262269@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 465649 [details].
Comment 9 Radar WebKit Bug Importer 2023-03-29 05:31:17 PDT
<rdar://problem/107363679>