chore: roll to Playwright v1.62.1

[lucastsudaka]

Rolls the bundled driver from v1.61.1 to v1.62.1 and ports the v1.62 client
surface, using the v1.62.0 Python and .NET rolls as
cross-binding references. .

New APIs

• ScrollMode (auto / none) on the affected action options.
• WebP screenshots, including path-based format inference.
• Virtual WebAuthn credentials in BrowserContext storage state.
• APIResponse.Timing().ResponseEnd.
• Locator.WaitForFunction.

Behavior changes ported

• Send per-call timeouts through protocol metadata, as required by the v1.62
  protocol.
• Acknowledge a screencast frame only after its callback completes, preserving
  driver backpressure and surfacing callback panics through the connection.
• Preserve responseEndTiming in API responses.

Fixes / internal

• Keep PLAYWRIGHT_CLI_PATH compatible with external driver layouts.
• Remove a pending protocol callback when its transport send fails.
• Align the bundled Node.js runtime with the official v1.62.1 roll.
• Regenerate the public Go API from the patched v1.62.1 documentation.

Protocol and generation notes

• packages/protocol/spec/*.yml is the Playwright client/driver wire-protocol
  source.
• The Go API generator consumes docs/src/api/*.md (including params.md),
  with Go language annotations supplied by patches/main.patch.
• Re-running generation from a clean v1.62.1 submodule produced no generated
  Go diff.

Validation

• gofumpt — clean
• golangci-lint run ./... — clean
• go vet ./... — passed
• BROWSER=chromium HEADLESS=1 go test -v --race ./... -count=1 — passed
• Fork CI matrix — passed on Linux, macOS, and Windows; Chromium, Firefox,
  and WebKit; stable and oldstable Go; lint and examples:
  https://github.com/lucastsudaka/playwright-go/actions/runs/31560409443

[mxschmitt]

hi, thank you for your contribution! Before I start reviewing it - did you use the https://github.com/mxschmitt/playwright-go/tree/main/.claude/skills/roll-playwright skill for it?

[lucastsudaka]

hi, thank you for your contribution! Before I start reviewing it - did you use the https://github.com/mxschmitt/playwright-go/tree/main/.claude/skills/roll-playwright skill for it?

Yes... followed the roll skill.
The API surface and tests were checked against all three sibling clients. Java was in that set
"cross-binding references"
I just left it out of the PR body 😅

• Java: microsoft/playwright-java#1951 (microsoft/playwright-java#1951) (1.62.0-alpha, per-upstream-PR breakdown) and #1954 (microsoft/playwright-java#1954) (1.62.0, including the interceptAPIRequests revert)

[mxschmitt]

Thanks for this — nice, thorough roll, and CI's fully green across the matrix. Went through it locally (incl. a security-focused pass) and have a few notes:

sanitizeStorageStateForAPIRequest (fetch.go) — good catch stripping Credentials before handing storage state to APIRequestContext.NewContext(); the protocol schema for that call only accepts cookies/origins, so this avoids sending a field the driver would reject. Confirmed it applies on both the in-memory and StorageStatePath-file-read paths.

Possible follow-up (not a blocker): BrowserContext.StorageState(..., Path) still writes the output file via plain os.Create (default 0666 & umask) in browser_context.go. That was already true before this PR, but this PR is the first time that file can optionally contain WebAuthn virtual-credential private keys (when Credentials: true is set). Low/medium severity since it's opt-in and these are synthetic test credentials, not live secrets — but worth tightening to 0600 given it can now carry key material. Happy to send a small follow-up PR for that if useful.

Nice fix: removing the orphaned pending-callback in connection.go when transport.Send fails is a real bug fix (leaked one *protocolCallback per failed send previously). Worth knowing this pattern is also present in playwright-java's Connection.internalSendMessage and playwright-dotnet's Connection.InnerSendMessageToServerAsync (both register the callback before the send with no cleanup on failure) — might be worth a heads-up issue on those repos.

One process note: the PR body cites Python and .NET as cross-binding references but not Java (the real Java roll was playwright-java#1951/#1954/#1959/#1961). Spot-checked for a resulting gap and didn't find one this time (the RouteFromHAR.InterceptAPIRequests option Java has looked like a miss at first glance, but Python's final 1.62.0 roll actually dropped that option before release, and this PR correctly matches that final state) — but worth checking all three references on future rolls since they don't always agree.

Nothing here blocks merging — great work overall. 🙏

[mxschmitt]

Reviewed locally (incl. a full security pass across two subagents) — see comment above for detailed notes. CI is green across the full matrix, no security blockers found, and the couple of follow-up suggestions (storage-state file permissions, citing all three sibling clients on future rolls) are non-blocking. Approving.