In Selenium, where on an element does WebElement.click() actually land, and how is that point computed?

## What the click command is actually asked to do A Java call such as `driver.findElement(By.cssSelector("[data-article='printer-jam']")).click()` sends one **Element Click** command to the remote end. The remote end does not "click the element". It scrolls the element's container into view if it is not already in view, computes a single coordinate called the **in-view centre point**, and dispatches a pointer sequence at that coordinate: a `pointerMove` whose origin is the element, then a `pointerDown` with `button` 0, then a `pointerUp`. Every surprise in this area follows from one fact: the target is **a pixel, not an element**. ## How the in-view centre point is computed 1. Call `getClientRects()` on the element and take **only the first** `DOMRect` in the collection. 2. Clamp that rectangle to the viewport: `left = max(0, ...)`, `right = min(innerWidth, ...)`, and the same treatment for `top` and `bottom` against `innerHeight`. 3. Take the midpoints of the clamped box and floor them: `x = floor((left + right) / 2)` and `y = floor((top + bottom) / 2)`. Two clauses in there do almost all of the damage in real suites: *first* rectangle, and *clamped to the viewport*. ## Why the first rectangle, and what it costs you On a helpdesk knowledge-base results list, an article title such as "Resolving a printer jam on the shared floor printers" is an inline `<a>` that wraps onto two lines. `getClientRects()` returns one rectangle per line box, and the spec takes the first. The click therefore lands in the middle of the **first line**, which is nearly always on the text. If instead you reason about the element's bounding box, you get a different answer: for a wide first line and a short second line, the union box's centre can fall in the empty space to the right of the second line, which belongs to the surrounding row and not to the link at all. The rule protects you here, but only if you know it exists: - Coordinates you compute yourself from a bounding box will **not** agree with where Selenium clicks. - An element whose `getClientRects()` list has length zero has no centre point at all. - The rule is per-element, so a wrapped link inside a card behaves differently from the card itself. ## Why clipping to the viewport matters The clamp is why a tall element behaves oddly. A knowledge-base article card taller than the viewport can never be fully on screen, so its centre point is the centre of **the part that overlaps the viewport** and moves as the page scrolls. That is usually what you want. It is also why "the element is visible" and "the element is clickable at its centre" are different statements. ## The paint tree at that one pixel The specification defines an element's **pointer-interactable paint tree** as the result of asking the document which elements are at the centre point, and calls an element **obscured** when that list is empty, or when the first entry in it is not the element itself or one of its descendants. So the real question the remote end asks is never "is this link visible?" but "is this link the top-most thing painted at exactly this coordinate?". Anything drawn over that pixel - a sticky filter bar above the results list, a floating chat launcher, a transparent scrim - answers it for you. | Common assumption | What the Element Click command does | |---|---| | It clicks the element | It clicks one coordinate and reaches whatever is painted there | | It uses the element's bounding box | It uses the **first** `DOMRect` from `getClientRects()` | | It uses the whole box even off-screen | It intersects that rectangle with the viewport first | | The centre is a fractional point | Both coordinates are floored to integers | | A visible element is clickable | Only visibility **at that one pixel** counts | ## What to do with this in a knowledge-base suite - Prefer clicking the smallest element that carries the affordance - the `<a>` inside the result row, not the row - so the pixel and the intent coincide. - Treat "the element is on screen" as insufficient evidence; the relevant property is what occupies its centre point. - Remember that `WebElement.click()` performs this computation **once** and dispatches immediately; it contains no retry of its own, so a point that is free a moment later is of no help to the command. - When a click reliably lands somewhere strange, reason about the first client rectangle and the viewport clamp before you reason about the application.