Files
ladybird/Tests/LibWeb/Text/input/SVG/removeChild-on-ancestor-of-use-element.html
Andreas Kling 34ec33d71c LibWeb: Don't treat SVG "use clone" removals as "use source" removals
We were failing to discriminate between DOM removals happening to SVG
elements cloned as part of an SVG use element instantiation.

When a "use source" element is removed, all clones of that source must
be updated to reflect the change. But when a "use clone" element is
removed, that's fine.

This was causing the surprising disappearance of use element subtrees,
seen for example on https://cal.com/
2025-08-07 22:15:36 +02:00

32 lines
921 B
HTML

<!doctype html>
<script src="../include.js"></script>
<div id="svgContainer1">
<svg><use id="use1" href="#foo" /></svg>
</div>
<div id="svgContainer2">
<svg><use id="use2" href="#foo" /></svg>
</div>
<svg id="foo"></svg>
<script>
function check(use) {
let sr = internals.getShadowRoot(use);
println(use.id + " > " + sr.firstChild + " " + sr.firstChild.id);
}
asyncTest((done) => {
// NOTE: We use setTimeout() here to ensure that the SVG use elements have had their shadow clone trees instantiated.
setTimeout(function() {
check(use1);
check(use2);
svgContainer1.remove();
// use1 is gone, but use2 should still have children!
try {
check(use1);
} catch (e) {
println("no use1");
}
check(use2);
done();
}, 10);
});
</script>