HTML Reporter since 2.14.0 doesn't add "flowing" elements to the page #1603
Description
As a result of #1513 in release 2.14.0, we are having trouble interacting with our own "elements under test" that are added to the document body, as these are no longer being shown.
Here is my HTML runner page, pointing to QUnit 2.13.0 CDN resources:
<html>
<head>
<title>My Title</title>
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/qunit/2.13.0/qunit.css">
<script src="https://cdnjs.cloudflare.com/ajax/libs/qunit/2.13.0/qunit.js"></script>
<script src="demo.js"></script>
</head>
<body>
<div id="qunit"></div>
<div id="qunit-fixture"></div>
</body>
</html>and this is the demo.js contents:
QUnit.test('test', assert => {
let button = document.createElement('button');
button.style.width = button.style.height = '100px';
document.body.appendChild(button);
let rect = button.getBoundingClientRect();
let center = [rect.left + rect.width/2, rect.top + rect.height/2];
let target = document.elementFromPoint(...center);
assert.strictEqual(target, button);
})With QUnit 2.13.0, this passes - the "target" element at the position of the added button element is indeed itself.
With QUnit 2.14.0, this fails, since the "target" that it finds is actually the QUnit banner.
We have a large testbed that exercises UI gestures (click, type, drag, etc) on various elements/widgets, and we need a place to put them into the page (and not shown here, but we diligently cleanup to avoid drool). With the fixed header, the tools can actually click the banner (instead of the button under test) which re-triggers the test run in a sort of infinite loop.
I tried to use the qunit-fixture div as my safe "sandbox" area, but that doesn't work either (nor did it before).
I'm looking for guidance on potential "test fixes" (a more robust way to write such tests), although admittedly that could mean a lot of cleanup for us. Otherwise I wonder if we can negotiate on the fixed headers - I really do like the improved UX, but the specific solution ended up making this upgrade (from 2.11.2, FWIW) an issue for our CI workflows.