div:after content is drawn after the first child of the element to which it's attached instead of after the last child node of that element. - latest Safari 2, Safari 3 (10.4.11), and WebKit nightly
Created attachment 17318 [details] test case Safari draws the :after content after the first child (#nav) instead of at the end of the #main element (after the <p/>).
Actually it looks like in this test case it's an extra piece of generated content. I imagine some incremental update fails to find/remove the old generated content for some reason, so you end up with two.
Created attachment 27686 [details] Patch (will land testcase in bug as regression test)
Comment on attachment 27686 [details] Patch (will land testcase in bug as regression test) This isn't quite right.
Created attachment 27690 [details] Another test case Ran into an example of this bug in WebKit-SVN-r40994. </test> and </expected_field_values> are showing up in the wrong places in Webkit compared to Presto and Gecko.
Created attachment 30518 [details] Yet another simple test case
Both issues - the incorrect placement and (sometimes) duplication - have been resolved. The first one in r56033 and the second - some time earlier. Currently all of the attached test cases render correctly, so I'm proposing to mark this bug as resolved.
(In reply to comment #7) > Both issues - the incorrect placement and (sometimes) duplication - have been > resolved. The first one in r56033 and the second - some time earlier. > > Currently all of the attached test cases render correctly, so I'm proposing to > mark this bug as resolved. I can't confirm that <https://bug-16019-attachments.webkit.org/attachment.cgi?id=27690> is fixed ("</test>" is in the wrong spot) with the latest win32 nightly 55974. However, webkit.exe often just loads safari without actually using the nightly files, so I'm not 100% it's not fixed.
> I can't confirm that > <https://bug-16019-attachments.webkit.org/attachment.cgi?id=27690> is fixed > ("</test>" is in the wrong spot) with the latest win32 nightly 55974. However, > webkit.exe often just loads safari without actually using the nightly files, so > I'm not 100% it's not fixed. The incorrect placement of ":after" generated content was fixed in 56033, so the version you are using is not recent enough.
I am not able to reproduce this bug in Safari 16.3 and STP 164 using "Yet Another simple test case", where all other browsers (Chrome Canary 112 and Firefox Nightly 112) match with Safari. Marking this "RESOLVED CONFIGURATION CHANGED". CCing others for any other input. Thanks!
Yeah, this looks to be fixed. Thank you for testing!