a focused child frame implies its parent document is focused
Whenever a child frame reports focus, this document reports focus too. Both unfocused, or parent-focused-child-not, are ordinary states.
What a detector infers
document.hasFocus() is true when the document OR any of its descendants holds focus, which makes it hierarchical rather than local: a focused child frame necessarily means its parent document reports focus too. That implication is the only thing assertable here, and the check asserts precisely it and nothing more.
Both documents reporting false is the ordinary state of a background tab; the parent reporting true while the child reports false simply means focus lives somewhere else in the page. Only the reverse — a child that claims focus while its parent denies it — is impossible, because focus cannot exist inside a frame without existing in the document that contains it.
The reason it is worth checking at all is that faking foregroundedness is a rational thing for automation to do: browsers throttle timers and rAF in background tabs, which slows a headless run badly, so tooling patches the page into claiming focus and visibility. Patching a hierarchical property in one document without its ancestors is the natural mistake, and it is what this reads. Severity is warn.
How to resolve it
Do not patch document.hasFocus() to claim foregroundedness — focus is hierarchical, so a claim made in one document has to hold for its ancestors as well, and a child that outranks its parent is impossible rather than merely unusual. Foreground the page rather than asserting that it is.
Read in the wild by
Kasada
Reads focus on both sides of the frame boundary, where the relationship is hierarchical.
document_has_focus, parent_document_has_focus
Kasada ips.js teardown — the full 427-probe listEvery attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Automation surface
- clicks landed on different points, not the same one repeatedly
pointer-landing-dispersionAiming is imprecise. A hand lands somewhere inside a control and the spread shows up within two or three clicks; a driver resolves the… - the button stayed pressed for the whole hold
hold-button-state-coherentThe gate's press-and-hold step asks for a button to be held for over a second, which is two orders of magnitude longer than a click's dwell… - the pointer travelled to each control it pressed
pointer-approach-per-targetThe gate asks for four separate acts in four separate places - three markers, a text field, a slider and a dropdown - and a pointer has to… - the pointer accelerated and slowed on its way to each control
pointer-approach-speed-profileA pointer moved by an arm leaves rest, accelerates, and brakes into its target, so the distance covered between consecutive samples rises… - no automation pointer-flash artifact is present
pointer-flash-keyframe-artifactThe only row on this page that works by recognising a specific string, which needs justifying because a name table is exactly what this… - pageXOffset/pageYOffset match their scrollX/scrollY aliases
scroll-alias-coherencewindow.pageXOffset is not a second scroll position, it is a legacy alias of window.scrollX — the specification defines them as the same… - no non-standard shadow-root escape hatch exists on Element.prototype
shadow-escape-hatch-absentClosed shadow roots exist to be unreachable: element.shadowRoot returns null for them, and that is the whole contract. - the markup this page was served with is the markup that reached the DOM
served-markup-integrityEvery other check on this page asks the browser about itself.
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Automation surface checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Automation surface — the family document-focus-vs-realm belongs to.