Bug 286403
| Summary: | :has(:empty) still applied after the content is changed to not be empty | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Keavon <keavon> |
| Component: | CSS | Assignee: | Antti Koivisto <koivisto> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | ahmad.saleem792, karlcow, koivisto, pp.koch, simon.fraser, webkit-bug-importer, zalan |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=286047 https://bugs.webkit.org/show_bug.cgi?id=311750 https://github.com/web-platform-tests/wpt/pull/59651 |
||
Keavon
Minimal reproduction:
Fiddle:
https://jsfiddle.net/5n1tb2sd/
HTML:
[<span>{<em></em>}</span>]
CSS:
span:has(em:empty) { color: red }
JS:
setTimeout(() => { document.querySelector("em").innerText = "no longer :empty so span shouldn't render this as red" }, 1000);
The expected behavior is that the curly brackets start out red for the first second, then the text appears (making <em> no longer :empty) and everything should become black. This works in Chrome and Firefox.
It is broken in Safari Version 18.1 (20619.2.8.11.10) which is the latest I can test through BrowserStack, it keeps the curly brackets and the added text red until I manage to force a repaint. Sometimes, merely opening dev tools causes it to repaint. Other times, I have to inspect the element and begin assigning it some CSS property or toggle an existing CSS property to force a repaint. To be clear, the red style is not applied to the <span> in dev tools, but it has been incorrectly painted red until the next repaint can be forced.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Resizing the window doesn't make the issue go away, so this is more than a repaint issue.
Karl Dubost
That seems related/similar to Bug 286047
Radar WebKit Bug Importer
<rdar://problem/143864358>
Peter-Paul Koch
I also encountered this bug and have more information as well as a simple test case and a workaround at https://quirksmode.org/browserbugs/safari-has-empty.html
Summary:
- y:has(x:empty) is checked for emptiness only one, between DOMContentLoaded and load.
- Emptiness is resolved incorrectly if element x is filled by a JavaScript onload AND the body overflows the html vertically, but not horizontally.
- If this is the case AND element y has CSS lengths in viewport units AND element x is currently filled, resizing the window updates the styles of element y once.
- a special case applies if y has display: none; see page
I probably got some of the details wrong, but I'm fairly certain of the gist.
Simon Fraser (smfr)
*** Bug 311750 has been marked as a duplicate of this bug. ***
Simon Fraser (smfr)
Pull request: https://github.com/WebKit/WebKit/pull/62402
Antti Koivisto
Pull request: https://github.com/WebKit/WebKit/pull/62436
EWS
Committed 310932@main (cc50c7dd8a0c): <https://commits.webkit.org/310932@main>
Reviewed commits have been landed. Closing PR #62436 and removing active labels.
EWS
Committed 305413.653@safari-7624-branch (9679268f8b84): <https://commits.webkit.org/305413.653@safari-7624-branch>
Reviewed commits have been landed. Closing PR #4921 and removing active labels.