Bug 254575

Summary: [css-lists] `content: counter()` does not update visually if `position: absolute` is set
Product: WebKit Reporter: Antoine Quint <graouts>
Component: CSSAssignee: alan <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

Antoine Quint
Reported 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.
Attachments
Test (666 bytes, text/html)
2023-03-28 04:30 PDT, Antoine Quint 		no flags
Details
Reduced test (239 bytes, text/html)
2023-03-28 06:10 PDT, Antoine Quint 		no flags
Details
[fast-cq]Patch (4.25 KB, patch)
2023-03-28 17:39 PDT, alan 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Antoine Quint
Comment 1 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()`.
Antoine Quint
Comment 2 2023-03-28 04:30:34 PDT
Created attachment 465629 [details] Test
Antoine Quint
Comment 3 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.
Antoine Quint
Comment 4 2023-03-28 06:08:03 PDT
Actually, the issue goes away if we remove the `position: absolute` style in `.counter:after`.
Antoine Quint
Comment 5 2023-03-28 06:10:17 PDT
Created attachment 465630 [details] Reduced test
Antoine Quint
Comment 6 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.
alan
Comment 7 2023-03-28 17:39:12 PDT
Created attachment 465649 [details] [fast-cq]Patch
EWS
Comment 8 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].
Radar WebKit Bug Importer
Comment 9 2023-03-29 05:31:17 PDT
<rdar://problem/107363679>
Note You need to log in before you can comment on or make changes to this bug.