Why this is tricky

Five independent scroll containers, each needing a different approach — a vertical box whose target sits below the fold and where "scroll the page" does nothing, a table wider than its container so whole columns are off-screen, a plain horizontally-scrolling strip with its own visible scrollbar, a list that only grows more DOM nodes when you scroll near its bottom, and a field that visually goes blank once scrolled away even though its value never changed. None of this is the page's own scrollbar, so window.scrollTo won't touch any of it.

1. Vertical scroll container

The target button sits inside its own scrollable region, independent of the page's scroll. Scroll within the container, or use the buttons below to test scroll-to-element strategies.

Item 1

Item 2

Item 3

Item 4

Item 5

Item 6

Item 7

Item 8

Item 9

Item 10

Item 11

Item 12

Item 13

Item 14

Item 15

Item 16

Item 17

Item 18

Item 19

Item 20


2. Horizontal scrollable table

A wide table — scroll right to see all columns. The Select button lives in the last one.


3. Scroll to load more

Only the loaded rows exist in the DOM — scrolling near the bottom fetches the next batch. Assert on the count, not just presence.

    Showing 10 items.


    4. Scroll-hidden input

    Type "Tosca" into the field below, then scroll it out of view — it visually goes blank once it leaves the box's visible area. Submit anyway: the real value is still there, this container just fakes emptiness once you can't see it.


    5. Horizontal scroll strip

    A plain horizontally-scrolling strip with its own visible scrollbar — no table, no wide columns, just a row wider than its container. The target card is the last one.

    Initial state.