Created attachment 469669 [details] testcase 1. Load the test case 2. Click on More Expected: Number 20 is displayed as - [20] - Actual: Number 17 is displayed as - [17] - Both Firefox and Chrome display - [20] - after the click.
Created attachment 469670 [details] rendering in safari, firefox, chrome after the click
<rdar://problem/122150415>
There is a shorter version there https://jsfiddle.net/Rolf_b/axjvuo5y/ But it is still a bit hard to understand what is happening. It would be great to be able to reduce the testcase to its absolute minimum, so that the WebKit engineers can clearly easily isolate what is happening.
ok. The testcase shows two cases (in fact 4 cases with more/less): The big purple number counts ALL the visible li elements. My first column is the li element count. Then the list structure with nested li/ul/li elements. 1 * A1 2 * A2 3 * A3 4 * A3.1 5 * A3.2 (hidden with display:none) 6 * A4 7 * A4.1 8 * A4.2 (hidden with display:none) 9 * A4.3 So we can see in the HTML, there are 9 li elements. The total count changes if and only if `::before` is used on all li elements to show the index on each li element. In Safari: ========== When all elements are shown (no us of display:none), the total count of li elements is: * 7 without ::before to display counter on each li element * 9 with ::before When some elements are hidden (aka two li hidden in the tests): the total count of li element is * 7 without ::before * 7 with ::before In Firefox/Chrome: ================== When all elements are shown (no us of display:none), the total count of li elements is: * 9 without ::before to display counter on each li element * 9 with ::before When some elements are hidden (aka two li hidden in the tests): the total count of li element is * 7 without ::before * 7 with ::before Safari doesn't count the li elements which start a nested list, textnode or not. (adding text nodes help to understand a bit more the test).
Created attachment 469720 [details] web inspector hmm I wonder if it's in fact an issue with nested parsing. See the attachment
Created attachment 469721 [details] testcase reduced, but not working That Said I have not been able to reproduce it yet. even with a more simplified test case.
Adding Matthieu just in case.
Might be something here: https://searchfox.org/wubkat/rev/5266b069f715d2051da7f1fc8def26d5dcd5e03c/Source/WebCore/rendering/RenderCounter.cpp#497
Safari got an update, the bug grew! Now ::after doesn’t count any more (in the code, where I found this thing). https://developer.apple.com/forums/thread/745708
Well, not only Safari … After first having an eye on „my“ bug in Safari, I thought “something else”? And: yes: FireFox doesn’t count too! No hint inside its inspector. But with a closer look I found: FireFox doesn’t apply the ::after to the li-elment. The ::after appears in it’s inspector after the included a. Instead of <li class…> <a …>…</a> </li> ::after … it shows up as <li class…> <a …>…</a> ::after … </li> Well, this isn’t the place where the stylesheet says “count” …
Latest update for Safari (und Preview) didn’t change the “broken ::after”. Just one thing happened: both, Safari and Firefox (updated too) don’t count any more in my case! All ::after show “1”. But only Safari shows an error(!?!) for the related CSS.