Summary

On mobile, after pressing Enter (in a list, paragraph, heading, table cell ...), the new caret often lands behind the on-screen keyboard. The browser's own auto-scroll only kicks in once the user starts typing, typically on the second character.
In a list this is particularly painful: users press Enter again, thinking nothing happened, which exits the list and destroys the item they were trying to add.

Before / After

• Before: Chrome / Android, long bullet list. Enter -> new item is hidden behind the keyboard until you type 2 characters.

• After: same scenario, scroll is immediate on Enter, no double-Enter, the new item appears above the keyboard.

Root cause

scrollIntoViewIfNeeded(LexicalUtils.ts) compares the selection rect against window.innerHeight in the body-scroll branch. On a desktop, layout viewport is more or less = visual viewport, so this is correct.
On mobile with the keyboard open, the layout viewport stays full-screen while the visual viewport shrinks to the area above the keyboard. The function therefore concludes the caret is already in view (currentBottom <= innerHeight) and does not scroll, even though visually the caret is behind the keyboard.

When the user starts typing, the browser's native auto-scroll-into-visual-viewport heuristic eventually catches up, that's why "the second character fixes it."

Fix

In the body-scroll branch, read window.visualViewport when available; fall back to innerHeight for environments without it.

const visualViewport = defaultView.visualViewport;
if (visualViewport) {
  const offsetTop = visualViewport.offsetTop;
  targetTop = offsetTop;
  targetBottom = offsetTop + visualViewport.height;
} else {
  targetTop = 0;
  targetBottom = getWindow(editor).innerHeight;
}

getBoundingClientRect already reports in layout-viewport coordinates, and visualViewport.offsetTop + height is the visible-area bottom in those same coordinates, so the surrounding math (currentBottom > targetBottom -> scrollBy(0, diff)) stays consistent.
The CSS scroll-padding accounting from #8218 is unchanged.
The non-body branch (in-editor overflow) is untouched.

Scope

The bug affects every Enter/return key that creates a new block: paragraphs, list items (<li>), headings, table cells, custom decorator nodes, and more generally any post-update selection change that hits the body-scroll branch.
Lists make it particularly user-visible because the natural workaround (press Enter again) destroys data. Fixing the underlying scroll math fixes all of them at once.

Test Plan

• New e2e test Auto scroll respects mobile visual viewport > Pressing Enter scrolls new caret above the on-screen keyboard (in packages/lexical-playground/__tests__/e2e/AutoScroll.spec.mjs):
  • Sets a 400*600 viewport, fills a bullet list past overflow, then stubs window.visualViewport via a real EventTarget that reports height: 300 and dispatches the resize event to mirror the real "keyboard appears" sequence.
  • Reads the caret position read-only via the element-anchor child rect (no DOM mutation, so Lexical's mutation observer / reconciler is not triggered).
  • Asserts caretRect.bottom <= visualViewport.offsetTop + visualViewport.height (so iOS-style non-zero offsetTop is also covered).
  • Fails before the fix with caretRect.bottom ~ 600 (sat at innerHeight, behind the simulated keyboard);
  • passes after with caretRect.bottom ~ 280.
• Existing "Auto scroll while typing" suite still passes. The fix only changes the body-scroll branch; tests that scroll the editor container itself (addScroll(...)) hit the unchanged else branch.
• Manual repro: Chrome on Android (real device), long bullet list at the bottom of the editor; before -> keyboard hides the new item until the second character; after -> immediate scroll on Enter.

Known limitations of the test setup

• The stub doesn't simulate the timing of a real keyboard animation (focus -> keyboard slides up -> relayout -> IME events). The synchronous read in scrollIntoViewIfNeeded doesn't depend on that timing, but a future iOS-specific test might want to.
• iOS WebKit offsetTop > 0 cases (visual viewport offset when the URL bar collapses) are exercised by the assertion math but not by the stub values