feat(e2e): scrollUntilVisible on a locator swipes that node, takes a momentum, and rejects unknown options

Merged
OK
1mo ago
+401-59
  • screen.scrollUntilVisible on a locator swipes that node, so a feed or a table that is its own scroll container pages without the pointer having to hover it first; on screen the viewport scrolls as before.
  • momentum option, the swipe grammar's 'none' | 'slow' | 'fast', 'slow' by default. An option the method does not take is INVALID_ARGUMENT, like every other verb's.
  • options.timeout bounds the whole scroll. Each swipe used to get config.actionTimeout of its own, so a slow one could outlive the scroll by that much; the swipes now run under the scroll's deadline, and one it cuts short is the scroll's LOCATOR_NOT_FOUND, with the engine error as its cause.
  • A locator made by another target's screen, or by an earlier attempt's, is INVALID_LOCATOR before any step: its expression would resolve through the wrong engine. scrollUntilVisible, dragTo, and filter({ has }) share the check.
await screen.getByRole('feed').scrollUntilVisible(row);
await table.scrollUntilVisible(claim, { timeout: 240_000 });
  • Unit tests cover the scoped swipe, the direction, the momentum, a hidden target, the deadline (a hung swipe fails within the scroll timeout, on screen and on a locator), the step label, the refused option, and the same-screen rule on all three methods. Docs in the screen reference; changeset e2e minor.

Devin Review