JavaScript elementFromPoint: find the element under viewport coordinates

Suppose a page editor draws a translucent review overlay above a notice. The author can see a button underneath, but a coordinate-based selection tool keeps finding the overlay. Inspecting the actual hit-test result helps distinguish an intercepted target from an incorrect coordinate conversion.

Start with the pointer's viewport position

In a development page, this listener reports the element at each pointer press without changing the page's normal click behavior:

document.addEventListener('pointerdown', event => {
  const hit = document.elementFromPoint(
    event.clientX,
    event.clientY
  );
  console.log(hit?.tagName ?? 'No element', hit);
}, { capture: true });

The returned value is an Element or null. A point outside the visible document, including a negative coordinate, can produce null, so avoid immediately reading .style or calling another method without checking the result.

This listener is a temporary diagnostic. Remove it when the investigation is finished rather than logging every interaction in the production editor. It reports the document's hit-test result at the coordinates, not a promise about which element every later event listener will receive.

Convert a known element's box into a point

To inspect what covers the center of a particular button:

function elementAtCenter(target) {
  const box = target.getBoundingClientRect();
  return document.elementFromPoint(
    box.left + box.width / 2,
    box.top + box.height / 2
  );
}

getBoundingClientRect() and elementFromPoint() both use the viewport coordinate system. Do not add scrollX or scrollY to this result. If the target is outside the viewport, scroll it into view and measure again before drawing a conclusion.

The returned element may be a child such as the button's text wrapper. If your selection tool needs the owning button, use an appropriate ancestor lookup such as hit?.closest('button'), then confirm that it belongs to the intended editing region. The lookup should reflect your application's permitted targets.

Inspect overlays without hiding the evidence

An overlay with normal pointer handling can be the topmost result even when it is translucent. When the overlay is purely decorative, CSS pointer-events can make it pass through hit testing. Apply that change only if the overlay should stop receiving pointer input.

For a diagnostic view of multiple hit-test candidates, inspect:

const stack = document.elementsFromPoint(x, y);
console.log(stack);

Here x and y must still be viewport coordinates. The array runs from topmost to bottommost. It is not a complete inventory of painted pixels: elements excluded by pointer handling do not become ordinary targets just because you ask for a stack. Multiple-element reference

Keep iframe coordinates in their own document

When a point falls inside an iframe, calling the method on the parent document returns the iframe element. It does not reach into the embedded document and return its internal button.

An application controlling a same-origin embedded page can perform a separate lookup within that document using coordinates appropriate to its viewport. A cross-origin frame requires cooperation through an allowed communication channel. Parent-document hit testing does not bypass that boundary.

Check the review overlay before and after scrolling the page. Compare its center hit with the expected button or overlay, then change only the pointer-handling rule the tool actually needs. Finish by confirming that the intended button still works with a normal click as well as through the coordinate diagnostic.