feat(evaluate): allow passing functions as evaluate arguments

[pavelfeldman]

Summary

• When evaluate is called with the exposeFunctions option, functions passed as (part of) the argument are exposed as page bindings with unguessable names and materialize as functions in the page; calling one returns a promise of the client-side result.
• Bindings are erased upon main frame navigation, scoping the callbacks to the execution context they were passed to.
• Without the option, passing a function throws as before.
• Works for page, frame, jsHandle and locator evaluate.
• Component testing now passes callback props through this mechanism, replacing the ordinal-based __ctDispatchFunction dispatch.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at the failing CI.

🔴 The tracing.spec.ts failure looks caused by this PR

library/tracing.spec.ts:780 › should not emit after w/o before fails deterministically on all three browsers (chromium incl. arm/node22/node24, firefox, webkit). It asserts the exact before/after call events recorded in a trace around page.evaluate, and this PR rewrites how evaluate serializes and dispatches its arguments and result — so the recorded call sequence shifts. That's a real, PR-caused failure, not a flake.

Details

Caused by this PR

• [chromium|firefox|webkit-library] › library/tracing.spec.ts:780 › should not emit after w/o before — the assertion at line 818 fails on every browser and both retries. The expected trace1 events are before (evaluate) → before "Wait for event console" → after, but the run records the "Wait for event console" title on the first before and shifts the others (Expected -1 / Received +3). The test exercises page.evaluate / page.evaluateHandle, exactly the code paths this PR reworks (client/channelOwner.ts, client/frame.ts, client/jsHandle.ts, client/page.ts, plus the serializers). A consistent, all-browser, all-retry failure on an evaluate-tracing test lines up with this diff rather than with infra noise. Worth checking whether the new evaluate dispatch emits/orders its trace call events differently, and either restoring the prior order or updating the expectation if the new order is intended.

Pre-existing flake / infra

• The 2 flaky entries — library/video.spec.ts:736 screencast › should work with video+trace and :699 › should capture full viewport on hidpi — passed on retry and are unrelated screencast flakes; nothing to triage there.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "MCP"

1 failed
❌ [chromium] › mcp/annotate.spec.ts:57 › should capture multiple screenshots in one annotation @mcp-macos-latest-chromium

7759 passed, 1249 skipped

---

Merge workflow run.

[github-actions]

Test results for "tests 1"

1 failed
❌ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace @frozen-time-library-chromium-linux

7 flaky

⚠️ [chromium-library] › library/chromium/chromium.spec.ts:177 › serviceWorker(), and fromServiceWorker() work `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/video.spec.ts:699 › screencast › should capture full viewport on hidpi `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:294 › screencast › should capture navigation `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/video.spec.ts:664 › screencast › should capture full viewport `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/video.spec.ts:699 › screencast › should capture full viewport on hidpi `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:434 › should produce network events, routing, and annotations for Service Worker (advanced) `@chromium-ubuntu-22.04-node22`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:388 › should reveal errors in the sourcetab `@windows-latest-node22`

49877 passed, 1156 skipped

---

Merge workflow run.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at the failing CI.

🔴 The tracing.spec.ts failure looks caused by this PR

library/tracing.spec.ts:780 › should not emit after w/o before fails deterministically on all three browsers, and the aggregated CI results show this test failing on no SHA other than this PR's — so it's a real, PR-caused failure, not a flake. The one MCP failure is a known unrelated flake.

Details

This PR reworks how evaluate serializes and dispatches its arguments and result (client/channelOwner.ts, client/frame.ts, client/jsHandle.ts, client/page.ts, plus the serializers), and the tracing test that broke asserts the exact before/after call events recorded around page.evaluate. That's exactly the code path the diff touches.

Caused by this PR

• [chromium|firefox|webkit-library] › library/tracing.spec.ts:780 › should not emit after w/o before — fails on every browser (chromium incl. arm / node22 / node24, firefox, webkit) and on both retries. In the aggregated results DB this test is otherwise green everywhere — chromium 6 failed / 1902 runs, firefox 1/387, webkit 1/380 — and every one of those failures is on PR feat(evaluate): allow passing functions as evaluate arguments #41801 (sha 39101ae3ed); no other SHA or PR has ever failed it. A consistent, all-browser, all-retry failure that appears only on this PR points at the diff, not infra. The test exercises page.evaluate / page.evaluateHandle and checks the recorded before → before "Wait for event console" → after sequence, so it's worth checking whether the new evaluate dispatch emits/orders its trace call events differently, and either restoring the prior order or updating the expectation if the new order is intended.

Pre-existing flake / infra

• [chromium] › mcp/annotate.spec.ts:57 › should capture multiple screenshots in one annotation (project chrome, mcp-macos-latest-chromium) — pre-existing flake. It failed once here (sha ca1e005be7) but the same test flakes all over the DB on SHAs this PR can't be responsible for: PRs chore: remove debian11 browser builds #41794, docs(test): mention webp as alternative snapshot format in toHaveScreenshot #41782, fix(video): avoid MJPEG interlace inference #41776, chore(recorder): turn preconditionSelector into an expect signal #41727, feat(webkit): roll to r2328 #41722, fix(mcp): skip ARIA snapshot serialization when snapshot-mode=none #41719, fix(webview): support input for elements inside cross-origin <iframe> #41463, chore(protocol): make timeout a protocol-level field #41712, test(firefox): fixme flaky proxy exclude-patterns on macOS #41703, test(screenshot): fix flaky "event loop is blocked" test #41688, and several push runs, going back a week-plus. project chrome alone is 14 failed / 442. This PR doesn't touch the MCP annotate flow. Note the earlier MCP run on this PR passed clean, then a re-run flipped it — classic flake.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Hi, I'm the Playwright bot and I took a look at the failing CI.

🟢 The PR is clear — the two remaining failures are known flakes

On the newest tested commit (ca1e005be7) the only two failures are video.spec.ts:736 and mcp/annotate.spec.ts:57, both pre-existing flakes that fail on main and unrelated PRs. The earlier all-browser tracing.spec.ts:780 failure was real and PR-caused, but it's already fixed on this commit.

Details

Fixed since the earlier red verdict

• [chromium|firefox|webkit-library] › library/tracing.spec.ts:780 › should not emit after w/o before — failed on all three browsers on the previous commit 39101ae3ed (8 failures) and was genuinely caused by this PR's evaluate rework. On the newer commit ca1e005be7 it passes on every browser, and in the aggregated results DB it has never failed on any SHA other than 39101ae3ed. Nothing left to do here.

Pre-existing flake / infra

• [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace — screencast video flake. Across the results DB this test is rescued-on-retry on dozens of main SHAs and unrelated PRs the PR can't be responsible for (rolls, skn0tt-parquet-reporter devops: report CI test results as parquet artifacts #41669, and literally a repro-video-recorder-flake branch fix(video): avoid MJPEG interlace inference #41776). It failed both attempts exactly once — here — out of 805 runs; every other appearance is a retry-rescued flake. This PR doesn't touch the screencast/video pipeline.

• [chromium] › mcp/annotate.spec.ts:57 › should capture multiple screenshots in one annotation — pre-existing MCP flake. Final-fails across PRs test(screenshot): fix flaky "event loop is blocked" test #41688, feat(ci): add fix-flakes workflow to auto-fix flaky tests #41692, chore(devops): don't pick already-fixed flakes in fix-flakes #41704, chore: remove debian11 browser builds #41794 and a main push (11a83314d0), spanning the chrome/firefox/webkit projects. This PR doesn't touch the MCP annotate flow. The earlier MCP run on this PR passed clean, then a re-run flipped it — classic flake.

_{Triaged by the Playwright bot.}

_{Triaged by the Playwright bot - agent run}