1934755 - CSS counters buggy when used in elements with style containment (`container` or `contain:style`)

Status: RESOLVED DUPLICATE of bug 1809505

(Core :: Layout: Generated Content, Lists, and Counters, defect)

Description

[stephenmerriman]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

Load the example here: https://jsfiddle.net/rgxLc46n/

Then press Ctrl-M to turn on responsive mode.

Actual results:

The counters change from 1, 2, 3, 4 to 2, 3, 4, 4. This does not happen if the container definition is removed.

Expected results:

CSS counters should be unaffected.

Note that this isn't restricted to responsive mode; I've had similar effects on proper HTML pages I'm working on by resizing the window past certain breakpoints that cause larger repaints (and sometimes the last counter changes to 0), but responsive mode is just being used as the simplest way to replicate this bug.

Comment 1

[stephenmerriman]

Sorry, Ctrl-Shift-M, obviously.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Generated Content, Lists, and Counters' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Attachment: testcase 1

Here's the reporter's testcase. I can reproduce.

The STR mention entering responsive design mode; but I can also reproduce by simply unchecking-re-checking the container declaration in Firefox's devtools. (Maybe entering RDM has that same effect by disabling/reenabling various styles as part of activating mobile-emulation stuff? Not sure.)

Comment 5

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Attachment: testcase 2 (no interaction required; automatically deactivates/reactivates 'container' style)

Comment 6

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Attachment: testcase 3 (now using `contain:style`)

container here only matters insomuch as it makes the element behave as if it had contain:style, I think.

Here's a testcase using contain:style instead of container. It still triggers the same issue.

Comment 7

[Daniel Holbert [:dholbert] (PTO until 2/24)]

With testcase 3, I can reproduce as far back as 2022-06-23 which is when contain:style started being parsed (via bug 1463600 comment 71). So this was a bug in our contain:style implementation when it was added.

This is probably a duplicate of bug 1809505 ("Style containment not working well with counters on pseudo-elements"), based on the name and based on the fact that the testcase here and on bug 1809505 both result in a one-time +1 increase to the counters during what-should-be-a-no-op style invalidation.