Element's display property affects composedPath() calculation unexpectedly #13070
Description
Below is a minimal reproducible example of the phenomenon.
<html lang="en">
<head>
<style>
.box {
width: 300px;
margin: 0 auto;
border: 1px solid black;
padding: 24px;
border-radius: 4px;
background-color: #f1f1f1;
}
.loading {
display: none;
position: fixed;
inset: 0;
z-index: 30000;
background-color: rgba(0, 0, 0, 0.2);
}
.loading.show {
display: block;
}
</style>
</head>
<body>
<div class="out">
<div class="box">
<h1>HELLO WORLD !</h1>
</div>
<div class="loading">test</div>
</div>
<script>
const loading = document.querySelector(".loading");
window.setInterval(() => {
loading.classList.toggle("show");
}, 1000);
function debug(e) {
console.log(e.composedPath()[0]);
}
window.addEventListener("click", debug);
</script>
</body>
</html>2025-11-05.5.38.50.mov
I created this HTML structure and JS logic, and continuously clicked on the location where .box is in the browser. I originally expected this behavior to cause the result printed by composedPath()[0] to alternate between the two elements .box and .loading, but surprisingly, .out appeared in between.
What I want to ask is, is there any part of the spec that mentions this behavior or logic? I asked the same question in whatwg/dom not long ago, but based on the responses I received and my subsequent experimental results, it is indeed related to CSS hit testing.