Webkit 174 should fix their implementation. See here: https://bugs.webkit.org/show_bug.cgi?id=258447

Fixing this would let pass two WPTs:

• https://wpt.fyi/results/css/css-counter-styles/cjk-earthly-branch/css3-counter-styles-202.html
• https://wpt.fyi/results/css/css-counter-styles/cjk-heavenly-stem/css3-counter-styles-205.html

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

For more information, please visit BugBot documentation.

They already do, what am I missing? https://searchfox.org/mozilla-central/rev/4e7b319091f2f9eddde7bb6810918dd5de23b709/layout/style/res/counterstyles.css#171,174,178,181

I'm not sure, it might even be a buggy WPT leading to different renderings:

• https://wpt.fyi/analyzer?screenshot=sha1%3Af57e8af8184400c9386364a98aa40c4dbf3a9583&screenshot=sha1%3A3d2bfa85373ad483a3fbf42361ea34f7cb9be1c9
• https://wpt.fyi/analyzer?screenshot=sha1%3A4092043b9f364967dbca676700261886618a6614&screenshot=sha1%3A1c2716a5a67695371e88b0bac0f75e850c07d199

Xidorn, not sure if you have time to look at this, it's probably something easy or a bogus test, but I'd have to dig more to figure out and not have the cycles r/n.

They are defined here in the code: https://searchfox.org/mozilla-central/rev/e4fa79ba05364da0d6ec40d3f9dbe0d15ce6f902/layout/style/res/counterstyles.css#171-183

Their system in our impl is alphabetic but in the spec it is fixed, which causes different behavior when out of the given range. The spec was changed on this in https://github.com/w3c/csswg-drafts/pull/4570 which happens after the last update to our impl.

To fix it we simply need to update the system as per the spec.

Thanks, Xidorn. Confirmed that just that trivial change does the trick. I've got a patch together; just giving it a quick try-run now.

Ok, my mach try auto run is as clean as expected: https://treeherder.mozilla.org/jobs?repo=try&revision=d2bfce408b5bbd75bd1aed40ba7be597c8facb51

https://hg.mozilla.org/mozilla-central/rev/e6bfaa522954