Knowing a control's location did not establish a clickable point. The center of a wrapped link's bounding box may be empty, and a popup can cover a button. I checked painted fragments and the actual element hit at a candidate point.

A bounding rectangle differs from painted fragments

A wrapped link's bounding rectangle includes spaces between its lines. Its center can belong to another control or an empty region. The point path examines a bounded number of client rectangles and searches candidate points within viewport and clipping bounds.

A wide card can also have a sibling menu over its center. Several defined interior points may be examined, but each must pass an actual hit test. This is not random clicking until something reacts. Only a checked point becomes a dispatch target.

Wait for the painted state after scrolling

Immediately after scrolling, DOM geometry and compositor hit testing can briefly differ. The point path waits for stable painted frames or its bounded fallback condition. Unsettled layout ends with an error rather than an infinite wait.

Connection, signature, visibility and disabled state are checked again afterward because the page may have changed while waiting. A layout wait is not permission to keep trusting an old reference. The point must still belong to the current node before dispatch.

Combine clipping estimates with the browser verdict

Overflow containers and bounds help estimate the clickable region, but fixed or absolute descendants can genuinely escape an intermediate ancestor's estimated clip. After conservative clipping, the implementation can still check an exposed point through the browser's real hit test.

That is not unconditional permission for covered controls. The hit or its ancestor must be the intended element. Genuinely clipped and overlay-covered targets fail. Actual painted behavior mediates between a false refusal based only on styles and a false acceptance that ignores occlusion.

Continue the same question through parent frames

A valid point inside a child document can still hit something else if its parent iframe is covered. Frame handling resolves the owner, converts coordinates and checks ancestors. Unsupported transforms are refused rather than guessed.

This differs from memorizing a screenshot coordinate and reusing it on another screen. The point comes from the current node and frame under current execution conditions. Coordinate-based operations are not interchangeable; their provenance and checks matter.

Check exposed fixed controls and truly covered ones

The fixed-control fixture checks a native click on a genuinely painted button outside a small overflow ancestor. A transformed, clipped variation must be refused without changing the result. The background-input test also refuses an overlay-covered click without increasing the commit count.

I read point calculation and those tests rather than hiding a user's real window or dispatching new clicks. A background application window also differs from a hidden DOM element. The background fixture separately checks preservation of window and throttling state after success and refusal. These are different conditions, not reasons to relax element occlusion checks. The fixture cases do not establish every CSS combination. Another failure needs a controlled reproduction of the actual structure.

Expose the reason a point is unavailable

An obscured-target error differs from an absent button. The caller can inspect a popup or reread the screen rather than switch blindly to a DOM click. Bypassing a point unavailable to a person can change the operation's intended meaning.

I wanted evidence for using a coordinate rather than numerical precision alone. Node, fragment, screen and parent frame are checked before one dispatch. Work automation becomes easier to verify and maintain when it can explain why the chosen point was considered correct.