[Feature]: keyboard.pressSequence() for batched named key presses

[SebTardif]

Feature Request

keyboard.type() batches character-level key presses into a single protocol message, processing all events server-side. There is no equivalent for named keys (Space, ArrowDown, Enter, etc.). Each keyboard.press() call requires a separate protocol round-trip.

Example

// Current: 5 protocol round-trips
await page.keyboard.press('Space');
await page.keyboard.press('ArrowDown');
await page.keyboard.press('ArrowDown');
await page.keyboard.press('ArrowDown');
await page.keyboard.press('Space');

// Proposed: 1 protocol round-trip
await page.keyboard.pressSequence(['Space', 'ArrowDown', 'ArrowDown', 'ArrowDown', 'Space'], { delay: 100 });

Each key entry follows the same format as keyboard.press(), including modifier shortcuts like Control+A.

Motivation

Keyboard-based drag-and-drop: Mouse-based dragTo() does not work with popular DnD libraries like react-beautiful-dnd and dnd-kit (#13855, #35749). The common workaround is keyboard-based reordering (Space/Arrow/Space), which requires multiple sequential keyboard.press() calls.

AI browser agents: Tools like browser-use, Playwright MCP, and other automation agents rely heavily on keyboard sequences for form navigation and drag-and-drop. Each keyboard.press() call incurs protocol serialization + WebSocket frame + async scheduling overhead. See browser-use#4683 for a related request about faster input methods.

Remote automation: When Playwright connects to a remote browser via connect() or connect_over_cdp(), network latency amplifies per-call overhead. A 5-key drag sequence goes from ~25ms locally to ~500ms+ over the network.

Unlike convenience wrappers, this cannot be replicated with page.evaluate(): CDP keyboard events go through the browser's native input pipeline (Input.dispatchKeyEvent), triggering IME, contenteditable, autocomplete, and framework-specific event handlers that synthetic dispatchEvent() calls do not.

A reference implementation is available in #40734.

[pavelfeldman]

We already have Locator.pressSequentially, I think we can tolerate an overload receiving an array as the first argument there, and mirror it on the locator-less Keyboard.pressSequentially.