a focused child frame implies its parent document is focused
Check id document-focus-vs-realm
What an ordinary browser yields
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
- user activation only ever appeared after a real input event
activation-without-inputThe row above this one reads navigator.userActivation once and expects it to be true, because the audit is reached by pressing a button. - the clicks this page received were real clicks
interaction-click-trustEvent.isTrusted is set by the engine when it dispatches an event it generated itself, and it cannot be set from script - a constructed… - every keypress had a keydown behind it
interaction-keypress-without-keydownThe UI Events spec generates keypress as the DEFAULT ACTION of a keydown - it is not an independent event, it is what a keydown does when it… - key events named the key they carried
interaction-key-identity-populatedA keypress the engine generates names the character it is delivering in .key. - the dropdown change came from the browser, not from a script
interaction-select-change-trustThe same isTrusted argument as the click row, on the surface where the shortcut is most common. - the dropdown fired input before change
interaction-select-input-precedes-changeHTML's "send select update notifications" steps fire input and THEN change when a selection is committed, so the pair is what the algorithm… - 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…
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.