Summary: | :empty selector with animation not working properly | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | ynagai | ||||||
Component: | CSS | Assignee: | Antoine Quint <graouts> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | ap, graouts, heycam, karlcow, koivisto, simon.fraser, webkit-bug-importer | ||||||
Priority: | P2 | Keywords: | BrowserCompat, InRadar | ||||||
Version: | Safari Technology Preview | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
See Also: | https://github.com/web-platform-tests/wpt/pull/44984 | ||||||||
Attachments: |
|
Description
ynagai
2024-02-08 23:45:22 PST
Thank you for the report! Could you please clarify if this a new issue Safari 17.4 beta and Technology Preview that does NOT affect shipping Safari? I confirmed that this issue does NOT happen in Safari 17.3. Here is what I am seeing when I click on the "Add Child" button: Chrome and Firefox: spinning blue square at the bottom becomes a static white square with "Child" label Safari 17.4 and STP 188: spinning blue square at the bottom remains blue and keeps spinning but also as a "Child" label Safari 17.3.1: spinning blue square at the bottom is unchanged Is the change between Safari 17.3.1 and Safari 17.4 described above what you are seeing as well? In either case, I believe we are not doing the right thing. My confirmation was incorrect. There seems to be something wrong with Safari 17.3.1 as well. I believe this is unrelated to animations and simply a style invalidation issue since the background-color remains stuck on blue. Querying the computed style from the Web Inspector addresses the issue. Created attachment 470209 [details]
Test
Actually I cannot make it happen without an `animation` property set on the element, so it does appear like animation is related to this issue.
Comment on attachment 470209 [details] Test <!DOCTYPE html> <html> <head> <title>WebKit Bug 269051</title> <style> .parent { width: 100px; height: 100px; background-color: green; } .parent:empty { background-color: red; animation: animation 1s; } @keyframes animation { } </style> </head> <body> <div class="parent"></div> <script> setTimeout(() => document.querySelector('.parent').appendChild(document.createElement('div')), 1000); </script> </body> </html> Created attachment 470210 [details]
Test
As the document is initially parsed, Document::finishedParsing() is called and eventually Element::setStyleAffectedByEmpty() is called on the <div> under Style::TreeResolver::styleForStyleable(). The call to setStyleAffectedByEmpty() will set the StyleAffectedByEmpty flag which will allow the static function checkForEmptyStyleChange() to not return early when style changes occur on that <div> element later. In the case where there is no `animation` style on that element, an additional call to Style::TreeResolver::resolveComposedTree() occurs due to a page rendering update and the <div> element is re-resolved. This time, when the <div> is visited, determineResolutionType() returns AnimationOnly and resetStyleRelations() is called, removing the StyleAffectedByEmpty flag. This explains the change in behavior with or without the `animation` style. I'm not sure how to deal with this yet. Should we avoid calling resetStyleRelations() or should we have another call to setStyleAffectedByEmpty() afterwards? Pull request: https://github.com/WebKit/WebKit/pull/25583 Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/44984 Committed 275832@main (319ecb9c28e3): <https://commits.webkit.org/275832@main> Reviewed commits have been landed. Closing PR #25583 and removing active labels. *** Bug 270885 has been marked as a duplicate of this bug. *** |