Bug 277230 – .class1:not(.class1:has(iframe), .class1:has(.class2)) behaves unexpectedly on webkit engines

• Component: CSS
• Status: RESOLVED DUPLICATE

[[e-mail]]

Not sure if this falls under CSS or Layout and Rendering, kinda under both.

The CSS rule .class1:not(.class1:has(iframe), .class1:has(.class2)) works perfectly fine on Chrome/Edge but fails on Safari v17.5 (or even Chrome on iOS so probably all webkit engines) when either the iframe or .class2 elements are removed and re-added.

I've currently had to resort to this just to avoid the above issue on webkit devices producing an extra padding-top during layout changes:
&.non-webkit .video:not(:has(iframe), :has(.fit-error)) {
    padding-top: 56.25%;
}

So take from that what you will, not sure which part in that rule is making webkit hiccup, but Chromium engines don't have that problem.

For context, the above rule, on page load (when the iframe is there), does not produce any extra padding-top as expected. But when I press a button that triggers the JS handler to remove the parent div of the iframe (directly inside .video) and then call a 3rd-party API to re-add that HTML (but with a new video), which takes about 300ms, BOOM! All of a sudden there's 56.25% padding-top on .video (I think this happens as soon as the removal of the iframe's parent div occurs). What's even more weird is that the CSS rule above is nowhere to be seen even though it's clearly being applied in the Inspect Element on webkit, something that's also not an issue in Chromium.

[Ahmad Saleem]

@Fuad - can you attach reproducible test case? it would help a lot.

[[e-mail]]

Created attachment 472011 [details]
Reproduces the CSS bug described in bug report

Steps to reproduce:
1. Press Add Iframe, red padding-top: 20% should disappear. It doesn't.
2. Press Remove Iframe.
3. Press Add Error, red padding-top: 20% should disappear. It does.
4. #1 should have the same behavior as #3.

The CSS lines of concern in this test case are:
&:not(:has(iframe), :has(.error)) {
                padding-top: 20%;
                background-color: #ff0000; /* Red background to visualize the padding */
            }

When I read the above line, I understand that padding-top: 20% and background-color: #ff0000 should ONLY be applied when .video does NOT have an iframe or a .error element. And that is exactly what you'd see on page load when there's no iframe or .error in .video. But then once you add an iframe, the padding-top: 20% and background-color #ff0000 should be gone, right? Well on Chromium they would be, but on webkit they're still there. Maybe webkit just understands this rule differently, but does it at least apply it consistently? It seems not. Because if we remove the iframe and add .error instead, it actually removes the padding-top: 20% and background-color: #ff0000... which is the expected behavior that should apply when iframe is added as well.

[[e-mail]]

@Ahmad just want to note that I added the reproducible test case so it isn't missed. And the comment above me highlights the steps to reproduce.

[Radar WebKit Bug Importer]

<rdar://problem/133165305>

[Karl Dubost]

Created attachment 472243 [details]
rendering in safari, firefox, chrome

Safari Technology Preview  201           20620.1.2
Firefox Nightly            131.0a1       13124.8.19
Google Chrome Canary       129.0.6667.0  6667.0

[Karl Dubost]

Another interesting details.
1. Open https://bug-277230-attachments.webkit.org/attachment.cgi?id=472011
2. Remove iframe
3. Open Web Inspector
4. select iframe
5. uncheck and recheck the CSS property `position: absolute`

The behavior is now correct.

[Matthieu Dubet]

*** This bug has been marked as a duplicate of bug 276771 ***