skip to content

In Selenium, what scrolling does WebElement.click() perform before clicking, and when does it skip it?

level: middleimportance: should knowfreq 52%

answer

  1. The driver does it, not your test
  2. It has a fixed alignment you cannot configure
  3. Not centred, and not to the top
  4. Bottom of element to bottom of viewport
  5. Skipped when already in its own paint tree

basics

~20 s

It calls scrollIntoView with instant behaviour, block end and inline nearest, so the bottom of the element is aligned with the bottom of the viewport. It skips the scroll when the element is already in view.

solid answer

~40 s

Scrolling is a step inside the WebDriver command, not something the test adds. The remote end calls `scrollIntoView` on the element with `behavior: "instant"`, `block: "end"` and `inline: "nearest"`, so the element finishes flush against the **bottom** of the viewport rather than centred. The step runs only when the element is not already in view, and "in view" is a hit test rather than a geometry test: the element must be the thing painted at its own centre point. `sendKeys` and `clear` scroll the same way. The scroll is not a wait and not a guarantee - after it, the command re-checks and reports the element as not interactable if the container is still not in view.

go deeper

for a junior

Recall that Selenium scrolls the element into view for you before clicking or typing, so adding your own scrolling step ahead of a click is usually redundant.

for a middle

Explain the specifics: instant behaviour, block end, inline nearest, run only when the element is not already in view, and the same preparation before sendKeys and clear.

for a senior

Use it diagnostically. Connect a failure that appears only at a smaller viewport to a different scroll outcome, and reason about what sits at the bottom edge of this particular layout.

for a principal

Own the layout consequence. A single sticky element at the foot of a page can degrade a large share of a suite, so treat bottom-edge page furniture as a testability question for the product team, not a per-test workaround.

## The scroll is part of the command, not something you add `WebElement.click()`, `WebElement.sendKeys(...)` and `WebElement.clear()` all begin by scrolling the target into view. You do not ask for it and you cannot configure it: it is a step inside the WebDriver command, run on the remote end before the pointer or key events are produced. Selenium's own documentation describes these basic element commands as designed to emulate a user's experience, and contrasts them on exactly this point with the lower-level Actions API, which does no such preparation for you. ## The exact scroll that is performed The remote end calls `scrollIntoView` on the element with three options fixed by the specification: | Option | Value | Consequence | |---|---|---| | `behavior` | `"instant"` | No animation; the command does not wait out a smooth scroll | | `block` | `"end"` | The **bottom** of the element is aligned with the bottom of the viewport | | `inline` | `"nearest"` | Horizontally it moves the least distance that brings the element in | `block: "end"` is the clause worth memorising. The element does not land in the middle of the screen and it does not land at the top: it ends up flush against the **bottom edge** of the viewport. On a helpdesk knowledge-base article, a "Was this helpful?" button at the foot of the page is scrolled until it sits on the bottom edge - which is also where cookie bars, consent strips, sticky feedback widgets and chat launchers live. ## When the scroll is skipped The specification runs the scroll **only if the element is not already in view**, and "in view" is not a bounding-box test. An element is in view when it is a member of its own **pointer-interactable paint tree**, given the pretence that its pointer events are not disabled - in other words, when asking the document what is painted at the element's centre point returns the element itself or a descendant of it. Two consequences follow, and neither is obvious: - An element fully on screen but painted under something else is **not** in view, so the command scrolls anyway. The scroll does not help, because whatever is on top moves with the element or is fixed. - An element already at a comfortable position is left where it is, so the same test can leave the page in two different scroll positions on two different viewport sizes. ## What the scroll is not 1. It is **not a wait.** The scroll happens, the checks run, and the command proceeds or fails; the Element Click steps contain no polling loop of their own. 2. It is **not a guarantee of success.** The command scrolls, then re-tests: if the container is still not in view afterwards, the command reports the element as not interactable rather than trying something else. 3. It is **not a scroll to the middle.** Anyone reasoning as though the element ends up centred will mispredict which page furniture ends up on top of it. ## Why this matters for a knowledge-base suite - Long articles are the worst case: every control below the fold is scrolled to the bottom edge, so a single sticky element at the foot of the layout can affect a large fraction of the suite at once. - A test that passes at 1280x1024 and fails at 1280x720 is often not a timing difference at all - it is a different scroll outcome, because a smaller viewport changes which elements were already in view. - Because the scroll is instant, no time passes for lazy-loaded content beneath the fold to arrive; the command's own steps do not account for anything the scroll triggers in the page. - Reasoning about the element's final position - flush with the bottom - is faster than re-running the test and is usually enough to explain a click that reached the wrong thing. ## A quick mental checklist - Did the element need scrolling at all, or was it already in its own paint tree at its centre point? - After the scroll, the element sits on the bottom edge: what is normally painted there on this page? - Does the layout change what is at the bottom edge at this viewport size? - Is the assumption "Selenium scrolled it, therefore it is usable" doing work in your reasoning that it cannot support?

  • Why can the built-in scroll leave an element under a sticky bar at the foot of the page?
    Because the scroll uses `block: "end"`, which aligns the bottom of the element with the bottom of the viewport. That is exactly where cookie strips, feedback widgets and chat launchers are anchored, so the element arrives underneath them rather than clear of them.
  • What does "already in view" mean for the purpose of skipping the scroll?
    It means the element is a member of its own pointer-interactable paint tree - the document reports the element or a descendant of it as the thing painted at its centre point. It is not a bounding-box calculation, so an on-screen element covered by something else counts as not in view.
  • Do sendKeys and clear scroll the element too?
    Yes. Both commands scroll the element into view before doing anything else, using the same options. They then wait for the element to become interactable, bounded by the session's implicit wait timeout, which the click command does not do.

saying these in an interview costs you the question

  • Thinks the element is scrolled to the centre of the viewport
  • Believes the built-in scroll guarantees the element is usable
  • Treats the scroll as a form of waiting for readiness
  • Assumes in view means the box overlaps the viewport
  • Says the test must scroll the element itself first