feat: support AbortSignal on server-side methods by Skn0tt · Pull Request #41141 · microsoft/playwright

Simon Knott (Skn0tt) · 2026-06-04T15:34:43Z

Summary

Adds a client-only signal?: AbortSignal option next to every existing timeout option on action, getter and navigation methods.
Aborting cancels the in-flight server call via a __cancel__ wire message that aborts the dispatcher's ProgressController; a pre-aborted signal throws signal.reason synchronously.
Internally, the signal travels as a required second argument on every client channel method, mirroring how progress works on the dispatcher side. That way the compiler enforces we forward it everywhere, rather than letting it hide in a params field.
Follows up feat: add AbortSignal support to client-side Waiter methods #41136 (Waiter-based waitFor* methods), which is excluded here as it already has signal support.

Not included (follow-ups)

expect assertions (toBeVisible, etc.) — deferred to a separate PR.
ElementHandle.inputValue — intentionally left out. Unlike Locator/Page/Frame.inputValue (which route through the Frame.inputValue protocol method that carries timeout), the ElementHandle.inputValue protocol method (packages/protocol/spec/handles.yml) declares no parameters, so the timeout option the public types have long advertised there is silently dropped by the wire validator. Adding signal would require a signature change and inherit that broken-timeout behavior. Fixing it is a separate change: add timeout/signal to the inputValue entry in handles.yml.

Dmitry Gozman (dgozman) · 2026-06-16T10:38:18Z


 async scrollIntoViewIfNeeded(options: channels.ElementHandleScrollIntoViewIfNeededOptions & TimeoutOptions = {}) {
- await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options) });
+ await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options), signal: options.signal });


In theory, can we replace timeouts with client-side signals that abort on timeout? Worth an experiment?

I think we could, yes! I'll try it out.

Threads an AbortSignal through the client as a required second argument on channel methods (mirroring progress on the dispatcher side), so server-side calls can be cancelled.

Simon Knott (Skn0tt) · 2026-06-18T10:21:56Z

Rebased onto #41321.

Aborting a channel call now rejects with an AbortError (mirroring Node.js abort-aware operations), preserving the original abort reason as cause instead of rethrowing the raw reason. This guarantees Playwright never throws a non-Error value when aborted with a string reason, in both the in-flight and already-aborted cases.

Dmitry Gozman (dgozman) · 2026-06-30T09:42:20Z

 evaluateHandle<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, R>, arg?: Arg, options?: { timeout?: number }): Promise<SmartHandle<R>>;
 evaluateAll<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E[], Arg, R>, arg?: Arg): Promise<R>;
- waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number }): Promise<void>;
+ waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number, signal?: AbortSignal }): Promise<void>;


What about other overrides here that have a timeout? I think these should get a signal as well.

i think there's many more missing, I'll do those chunked in follow-ups.

…erver-side

github-actions · 2026-06-30T11:55:43Z

Test results for "MCP"

3 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-chrome
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-firefox

7458 passed, 1132 skipped

Merge workflow run.

github-actions · 2026-06-30T12:00:16Z

Test results for "tests 1"

2 failed
❌ [chromium-library] › library/browsercontext-add-init-script.spec.ts:28 › should work without navigation, after all bindings @chromium-ubuntu-22.04-arm-node20
❌ [chromium-library] › library/browsercontext-expose-function.spec.ts:77 › should be callable from-inside addInitScript @chromium-ubuntu-22.04-arm-node20

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:476 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/video.spec.ts:717 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`

49217 passed, 1163 skipped

Merge workflow run.

Simon Knott (Skn0tt) · 2026-06-04T15:34:43Z

Summary

Adds a client-only signal?: AbortSignal option next to every existing timeout option on action, getter and navigation methods.
Aborting cancels the in-flight server call via a __cancel__ wire message that aborts the dispatcher's ProgressController; a pre-aborted signal throws signal.reason synchronously.
Internally, the signal travels as a required second argument on every client channel method, mirroring how progress works on the dispatcher side. That way the compiler enforces we forward it everywhere, rather than letting it hide in a params field.
Follows up feat: add AbortSignal support to client-side Waiter methods #41136 (Waiter-based waitFor* methods), which is excluded here as it already has signal support.

Not included (follow-ups)

expect assertions (toBeVisible, etc.) — deferred to a separate PR.
ElementHandle.inputValue — intentionally left out. Unlike Locator/Page/Frame.inputValue (which route through the Frame.inputValue protocol method that carries timeout), the ElementHandle.inputValue protocol method (packages/protocol/spec/handles.yml) declares no parameters, so the timeout option the public types have long advertised there is silently dropped by the wire validator. Adding signal would require a signature change and inherit that broken-timeout behavior. Fixing it is a separate change: add timeout/signal to the inputValue entry in handles.yml.

Refs #40578

Dmitry Gozman (dgozman) · 2026-06-16T10:38:18Z


 async scrollIntoViewIfNeeded(options: channels.ElementHandleScrollIntoViewIfNeededOptions & TimeoutOptions = {}) {
- await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options) });
+ await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options), signal: options.signal });


In theory, can we replace timeouts with client-side signals that abort on timeout? Worth an experiment?

I think we could, yes! I'll try it out.

Threads an AbortSignal through the client as a required second argument on channel methods (mirroring progress on the dispatcher side), so server-side calls can be cancelled.

Simon Knott (Skn0tt) · 2026-06-18T10:21:56Z

Rebased onto #41321.

Aborting a channel call now rejects with an AbortError (mirroring Node.js abort-aware operations), preserving the original abort reason as cause instead of rethrowing the raw reason. This guarantees Playwright never throws a non-Error value when aborted with a string reason, in both the in-flight and already-aborted cases.

Dmitry Gozman (dgozman) · 2026-06-30T09:42:20Z

 evaluateHandle<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, R>, arg?: Arg, options?: { timeout?: number }): Promise<SmartHandle<R>>;
 evaluateAll<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E[], Arg, R>, arg?: Arg): Promise<R>;
- waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number }): Promise<void>;
+ waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number, signal?: AbortSignal }): Promise<void>;


What about other overrides here that have a timeout? I think these should get a signal as well.

i think there's many more missing, I'll do those chunked in follow-ups.

…erver-side

github-actions · 2026-06-30T11:55:43Z

Test results for "MCP"

3 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-chrome
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-firefox

7458 passed, 1132 skipped

Merge workflow run.

github-actions · 2026-06-30T12:00:16Z

Test results for "tests 1"

2 failed
❌ [chromium-library] › library/browsercontext-add-init-script.spec.ts:28 › should work without navigation, after all bindings @chromium-ubuntu-22.04-arm-node20
❌ [chromium-library] › library/browsercontext-expose-function.spec.ts:77 › should be callable from-inside addInitScript @chromium-ubuntu-22.04-arm-node20

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:476 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/video.spec.ts:717 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`

49217 passed, 1163 skipped

Merge workflow run.

Simon Knott (Skn0tt) · 2026-06-04T15:34:43Z

Summary

Adds a client-only signal?: AbortSignal option next to every existing timeout option on action, getter and navigation methods.
Aborting cancels the in-flight server call via a __cancel__ wire message that aborts the dispatcher's ProgressController; a pre-aborted signal throws signal.reason synchronously.
Internally, the signal travels as a required second argument on every client channel method, mirroring how progress works on the dispatcher side. That way the compiler enforces we forward it everywhere, rather than letting it hide in a params field.
Follows up feat: add AbortSignal support to client-side Waiter methods #41136 (Waiter-based waitFor* methods), which is excluded here as it already has signal support.

Not included (follow-ups)

expect assertions (toBeVisible, etc.) — deferred to a separate PR.
ElementHandle.inputValue — intentionally left out. Unlike Locator/Page/Frame.inputValue (which route through the Frame.inputValue protocol method that carries timeout), the ElementHandle.inputValue protocol method (packages/protocol/spec/handles.yml) declares no parameters, so the timeout option the public types have long advertised there is silently dropped by the wire validator. Adding signal would require a signature change and inherit that broken-timeout behavior. Fixing it is a separate change: add timeout/signal to the inputValue entry in handles.yml.

Refs #40578

Dmitry Gozman (dgozman) · 2026-06-16T10:38:18Z


 async scrollIntoViewIfNeeded(options: channels.ElementHandleScrollIntoViewIfNeededOptions & TimeoutOptions = {}) {
- await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options) });
+ await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options), signal: options.signal });


In theory, can we replace timeouts with client-side signals that abort on timeout? Worth an experiment?

I think we could, yes! I'll try it out.

Threads an AbortSignal through the client as a required second argument on channel methods (mirroring progress on the dispatcher side), so server-side calls can be cancelled.

Simon Knott (Skn0tt) · 2026-06-18T10:21:56Z

Rebased onto #41321.

Aborting a channel call now rejects with an AbortError (mirroring Node.js abort-aware operations), preserving the original abort reason as cause instead of rethrowing the raw reason. This guarantees Playwright never throws a non-Error value when aborted with a string reason, in both the in-flight and already-aborted cases.

Dmitry Gozman (dgozman) · 2026-06-30T09:42:20Z

 evaluateHandle<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, R>, arg?: Arg, options?: { timeout?: number }): Promise<SmartHandle<R>>;
 evaluateAll<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E[], Arg, R>, arg?: Arg): Promise<R>;
- waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number }): Promise<void>;
+ waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number, signal?: AbortSignal }): Promise<void>;


What about other overrides here that have a timeout? I think these should get a signal as well.

i think there's many more missing, I'll do those chunked in follow-ups.

…erver-side

github-actions · 2026-06-30T11:55:43Z

Test results for "MCP"

3 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-chrome
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-firefox

7458 passed, 1132 skipped

Merge workflow run.

github-actions · 2026-06-30T12:00:16Z

Test results for "tests 1"

2 failed
❌ [chromium-library] › library/browsercontext-add-init-script.spec.ts:28 › should work without navigation, after all bindings @chromium-ubuntu-22.04-arm-node20
❌ [chromium-library] › library/browsercontext-expose-function.spec.ts:77 › should be callable from-inside addInitScript @chromium-ubuntu-22.04-arm-node20

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:476 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/video.spec.ts:717 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`

49217 passed, 1163 skipped

Merge workflow run.

Simon Knott (Skn0tt) · 2026-06-04T15:34:43Z

Summary

Adds a client-only signal?: AbortSignal option next to every existing timeout option on action, getter and navigation methods.
Aborting cancels the in-flight server call via a __cancel__ wire message that aborts the dispatcher's ProgressController; a pre-aborted signal throws signal.reason synchronously.
Internally, the signal travels as a required second argument on every client channel method, mirroring how progress works on the dispatcher side. That way the compiler enforces we forward it everywhere, rather than letting it hide in a params field.
Follows up feat: add AbortSignal support to client-side Waiter methods #41136 (Waiter-based waitFor* methods), which is excluded here as it already has signal support.

Not included (follow-ups)

expect assertions (toBeVisible, etc.) — deferred to a separate PR.
ElementHandle.inputValue — intentionally left out. Unlike Locator/Page/Frame.inputValue (which route through the Frame.inputValue protocol method that carries timeout), the ElementHandle.inputValue protocol method (packages/protocol/spec/handles.yml) declares no parameters, so the timeout option the public types have long advertised there is silently dropped by the wire validator. Adding signal would require a signature change and inherit that broken-timeout behavior. Fixing it is a separate change: add timeout/signal to the inputValue entry in handles.yml.

Refs #40578

Dmitry Gozman (dgozman) · 2026-06-16T10:38:18Z


 async scrollIntoViewIfNeeded(options: channels.ElementHandleScrollIntoViewIfNeededOptions & TimeoutOptions = {}) {
- await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options) });
+ await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options), signal: options.signal });


In theory, can we replace timeouts with client-side signals that abort on timeout? Worth an experiment?

I think we could, yes! I'll try it out.

Threads an AbortSignal through the client as a required second argument on channel methods (mirroring progress on the dispatcher side), so server-side calls can be cancelled.

Simon Knott (Skn0tt) · 2026-06-18T10:21:56Z

Rebased onto #41321.

Aborting a channel call now rejects with an AbortError (mirroring Node.js abort-aware operations), preserving the original abort reason as cause instead of rethrowing the raw reason. This guarantees Playwright never throws a non-Error value when aborted with a string reason, in both the in-flight and already-aborted cases.

Dmitry Gozman (dgozman) · 2026-06-30T09:42:20Z

 evaluateHandle<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, R>, arg?: Arg, options?: { timeout?: number }): Promise<SmartHandle<R>>;
 evaluateAll<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E[], Arg, R>, arg?: Arg): Promise<R>;
- waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number }): Promise<void>;
+ waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number, signal?: AbortSignal }): Promise<void>;


What about other overrides here that have a timeout? I think these should get a signal as well.

i think there's many more missing, I'll do those chunked in follow-ups.

…erver-side

github-actions · 2026-06-30T11:55:43Z

Test results for "MCP"

3 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-chrome
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-firefox

7458 passed, 1132 skipped

Merge workflow run.

github-actions · 2026-06-30T12:00:16Z

Test results for "tests 1"

2 failed
❌ [chromium-library] › library/browsercontext-add-init-script.spec.ts:28 › should work without navigation, after all bindings @chromium-ubuntu-22.04-arm-node20
❌ [chromium-library] › library/browsercontext-expose-function.spec.ts:77 › should be callable from-inside addInitScript @chromium-ubuntu-22.04-arm-node20

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:476 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/video.spec.ts:717 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`

49217 passed, 1163 skipped

Merge workflow run.

Simon Knott (Skn0tt) · 2026-06-04T15:34:43Z

Summary

Adds a client-only signal?: AbortSignal option next to every existing timeout option on action, getter and navigation methods.
Aborting cancels the in-flight server call via a __cancel__ wire message that aborts the dispatcher's ProgressController; a pre-aborted signal throws signal.reason synchronously.
Internally, the signal travels as a required second argument on every client channel method, mirroring how progress works on the dispatcher side. That way the compiler enforces we forward it everywhere, rather than letting it hide in a params field.
Follows up feat: add AbortSignal support to client-side Waiter methods #41136 (Waiter-based waitFor* methods), which is excluded here as it already has signal support.

Not included (follow-ups)

expect assertions (toBeVisible, etc.) — deferred to a separate PR.
ElementHandle.inputValue — intentionally left out. Unlike Locator/Page/Frame.inputValue (which route through the Frame.inputValue protocol method that carries timeout), the ElementHandle.inputValue protocol method (packages/protocol/spec/handles.yml) declares no parameters, so the timeout option the public types have long advertised there is silently dropped by the wire validator. Adding signal would require a signature change and inherit that broken-timeout behavior. Fixing it is a separate change: add timeout/signal to the inputValue entry in handles.yml.

Refs #40578

Dmitry Gozman (dgozman) · 2026-06-16T10:38:18Z


 async scrollIntoViewIfNeeded(options: channels.ElementHandleScrollIntoViewIfNeededOptions & TimeoutOptions = {}) {
- await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options) });
+ await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options), signal: options.signal });


In theory, can we replace timeouts with client-side signals that abort on timeout? Worth an experiment?

I think we could, yes! I'll try it out.

Threads an AbortSignal through the client as a required second argument on channel methods (mirroring progress on the dispatcher side), so server-side calls can be cancelled.

Simon Knott (Skn0tt) · 2026-06-18T10:21:56Z

Rebased onto #41321.

Aborting a channel call now rejects with an AbortError (mirroring Node.js abort-aware operations), preserving the original abort reason as cause instead of rethrowing the raw reason. This guarantees Playwright never throws a non-Error value when aborted with a string reason, in both the in-flight and already-aborted cases.

Dmitry Gozman (dgozman) · 2026-06-30T09:42:20Z

 evaluateHandle<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, R>, arg?: Arg, options?: { timeout?: number }): Promise<SmartHandle<R>>;
 evaluateAll<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E[], Arg, R>, arg?: Arg): Promise<R>;
- waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number }): Promise<void>;
+ waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number, signal?: AbortSignal }): Promise<void>;


What about other overrides here that have a timeout? I think these should get a signal as well.

i think there's many more missing, I'll do those chunked in follow-ups.

…erver-side

github-actions · 2026-06-30T11:55:43Z

Test results for "MCP"

3 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-chrome
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-firefox

7458 passed, 1132 skipped

Merge workflow run.

github-actions · 2026-06-30T12:00:16Z

Test results for "tests 1"

2 failed
❌ [chromium-library] › library/browsercontext-add-init-script.spec.ts:28 › should work without navigation, after all bindings @chromium-ubuntu-22.04-arm-node20
❌ [chromium-library] › library/browsercontext-expose-function.spec.ts:77 › should be callable from-inside addInitScript @chromium-ubuntu-22.04-arm-node20

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:476 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/video.spec.ts:717 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`

49217 passed, 1163 skipped

Merge workflow run.

Simon Knott (Skn0tt) · 2026-06-04T15:34:43Z

Summary

Adds a client-only signal?: AbortSignal option next to every existing timeout option on action, getter and navigation methods.
Aborting cancels the in-flight server call via a __cancel__ wire message that aborts the dispatcher's ProgressController; a pre-aborted signal throws signal.reason synchronously.
Internally, the signal travels as a required second argument on every client channel method, mirroring how progress works on the dispatcher side. That way the compiler enforces we forward it everywhere, rather than letting it hide in a params field.
Follows up feat: add AbortSignal support to client-side Waiter methods #41136 (Waiter-based waitFor* methods), which is excluded here as it already has signal support.

Not included (follow-ups)

expect assertions (toBeVisible, etc.) — deferred to a separate PR.
ElementHandle.inputValue — intentionally left out. Unlike Locator/Page/Frame.inputValue (which route through the Frame.inputValue protocol method that carries timeout), the ElementHandle.inputValue protocol method (packages/protocol/spec/handles.yml) declares no parameters, so the timeout option the public types have long advertised there is silently dropped by the wire validator. Adding signal would require a signature change and inherit that broken-timeout behavior. Fixing it is a separate change: add timeout/signal to the inputValue entry in handles.yml.

Refs #40578

Dmitry Gozman (dgozman) · 2026-06-16T10:38:18Z


 async scrollIntoViewIfNeeded(options: channels.ElementHandleScrollIntoViewIfNeededOptions & TimeoutOptions = {}) {
- await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options) });
+ await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options), signal: options.signal });


In theory, can we replace timeouts with client-side signals that abort on timeout? Worth an experiment?

I think we could, yes! I'll try it out.

Threads an AbortSignal through the client as a required second argument on channel methods (mirroring progress on the dispatcher side), so server-side calls can be cancelled.

Simon Knott (Skn0tt) · 2026-06-18T10:21:56Z

Rebased onto #41321.

Aborting a channel call now rejects with an AbortError (mirroring Node.js abort-aware operations), preserving the original abort reason as cause instead of rethrowing the raw reason. This guarantees Playwright never throws a non-Error value when aborted with a string reason, in both the in-flight and already-aborted cases.

Dmitry Gozman (dgozman) · 2026-06-30T09:42:20Z

 evaluateHandle<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, R>, arg?: Arg, options?: { timeout?: number }): Promise<SmartHandle<R>>;
 evaluateAll<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E[], Arg, R>, arg?: Arg): Promise<R>;
- waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number }): Promise<void>;
+ waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number, signal?: AbortSignal }): Promise<void>;


What about other overrides here that have a timeout? I think these should get a signal as well.

i think there's many more missing, I'll do those chunked in follow-ups.

…erver-side

github-actions · 2026-06-30T11:55:43Z

Test results for "MCP"

3 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-chrome
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-firefox

7458 passed, 1132 skipped

Merge workflow run.

github-actions · 2026-06-30T12:00:16Z

Test results for "tests 1"

2 failed
❌ [chromium-library] › library/browsercontext-add-init-script.spec.ts:28 › should work without navigation, after all bindings @chromium-ubuntu-22.04-arm-node20
❌ [chromium-library] › library/browsercontext-expose-function.spec.ts:77 › should be callable from-inside addInitScript @chromium-ubuntu-22.04-arm-node20

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:476 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/video.spec.ts:717 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`

49217 passed, 1163 skipped

Merge workflow run.

Simon Knott (Skn0tt) · 2026-06-04T15:34:43Z

Summary

Adds a client-only signal?: AbortSignal option next to every existing timeout option on action, getter and navigation methods.
Aborting cancels the in-flight server call via a __cancel__ wire message that aborts the dispatcher's ProgressController; a pre-aborted signal throws signal.reason synchronously.
Internally, the signal travels as a required second argument on every client channel method, mirroring how progress works on the dispatcher side. That way the compiler enforces we forward it everywhere, rather than letting it hide in a params field.
Follows up feat: add AbortSignal support to client-side Waiter methods #41136 (Waiter-based waitFor* methods), which is excluded here as it already has signal support.

Not included (follow-ups)

expect assertions (toBeVisible, etc.) — deferred to a separate PR.
ElementHandle.inputValue — intentionally left out. Unlike Locator/Page/Frame.inputValue (which route through the Frame.inputValue protocol method that carries timeout), the ElementHandle.inputValue protocol method (packages/protocol/spec/handles.yml) declares no parameters, so the timeout option the public types have long advertised there is silently dropped by the wire validator. Adding signal would require a signature change and inherit that broken-timeout behavior. Fixing it is a separate change: add timeout/signal to the inputValue entry in handles.yml.

Refs #40578

Dmitry Gozman (dgozman) · 2026-06-16T10:38:18Z


 async scrollIntoViewIfNeeded(options: channels.ElementHandleScrollIntoViewIfNeededOptions & TimeoutOptions = {}) {
- await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options) });
+ await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options), signal: options.signal });


In theory, can we replace timeouts with client-side signals that abort on timeout? Worth an experiment?

I think we could, yes! I'll try it out.

Threads an AbortSignal through the client as a required second argument on channel methods (mirroring progress on the dispatcher side), so server-side calls can be cancelled.

Simon Knott (Skn0tt) · 2026-06-18T10:21:56Z

Rebased onto #41321.

Aborting a channel call now rejects with an AbortError (mirroring Node.js abort-aware operations), preserving the original abort reason as cause instead of rethrowing the raw reason. This guarantees Playwright never throws a non-Error value when aborted with a string reason, in both the in-flight and already-aborted cases.

Dmitry Gozman (dgozman) · 2026-06-30T09:42:20Z

 evaluateHandle<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, R>, arg?: Arg, options?: { timeout?: number }): Promise<SmartHandle<R>>;
 evaluateAll<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E[], Arg, R>, arg?: Arg): Promise<R>;
- waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number }): Promise<void>;
+ waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number, signal?: AbortSignal }): Promise<void>;


What about other overrides here that have a timeout? I think these should get a signal as well.

i think there's many more missing, I'll do those chunked in follow-ups.

…erver-side

github-actions · 2026-06-30T11:55:43Z

Test results for "MCP"

3 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-chrome
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-firefox

7458 passed, 1132 skipped

Merge workflow run.

github-actions · 2026-06-30T12:00:16Z

Test results for "tests 1"

2 failed
❌ [chromium-library] › library/browsercontext-add-init-script.spec.ts:28 › should work without navigation, after all bindings @chromium-ubuntu-22.04-arm-node20
❌ [chromium-library] › library/browsercontext-expose-function.spec.ts:77 › should be callable from-inside addInitScript @chromium-ubuntu-22.04-arm-node20

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:476 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/video.spec.ts:717 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`

49217 passed, 1163 skipped

Merge workflow run.

Simon Knott (Skn0tt) · 2026-06-04T15:34:43Z

Summary

Adds a client-only signal?: AbortSignal option next to every existing timeout option on action, getter and navigation methods.
Aborting cancels the in-flight server call via a __cancel__ wire message that aborts the dispatcher's ProgressController; a pre-aborted signal throws signal.reason synchronously.
Internally, the signal travels as a required second argument on every client channel method, mirroring how progress works on the dispatcher side. That way the compiler enforces we forward it everywhere, rather than letting it hide in a params field.
Follows up feat: add AbortSignal support to client-side Waiter methods #41136 (Waiter-based waitFor* methods), which is excluded here as it already has signal support.

Not included (follow-ups)

expect assertions (toBeVisible, etc.) — deferred to a separate PR.
ElementHandle.inputValue — intentionally left out. Unlike Locator/Page/Frame.inputValue (which route through the Frame.inputValue protocol method that carries timeout), the ElementHandle.inputValue protocol method (packages/protocol/spec/handles.yml) declares no parameters, so the timeout option the public types have long advertised there is silently dropped by the wire validator. Adding signal would require a signature change and inherit that broken-timeout behavior. Fixing it is a separate change: add timeout/signal to the inputValue entry in handles.yml.

Refs #40578

Dmitry Gozman (dgozman) · 2026-06-16T10:38:18Z


 async scrollIntoViewIfNeeded(options: channels.ElementHandleScrollIntoViewIfNeededOptions & TimeoutOptions = {}) {
- await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options) });
+ await this._elementChannel.scrollIntoViewIfNeeded({ ...options, timeout: this._frame._timeout(options), signal: options.signal });


In theory, can we replace timeouts with client-side signals that abort on timeout? Worth an experiment?

I think we could, yes! I'll try it out.

Threads an AbortSignal through the client as a required second argument on channel methods (mirroring progress on the dispatcher side), so server-side calls can be cancelled.

Simon Knott (Skn0tt) · 2026-06-18T10:21:56Z

Rebased onto #41321.

Aborting a channel call now rejects with an AbortError (mirroring Node.js abort-aware operations), preserving the original abort reason as cause instead of rethrowing the raw reason. This guarantees Playwright never throws a non-Error value when aborted with a string reason, in both the in-flight and already-aborted cases.

Dmitry Gozman (dgozman) · 2026-06-30T09:42:20Z

 evaluateHandle<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, R>, arg?: Arg, options?: { timeout?: number }): Promise<SmartHandle<R>>;
 evaluateAll<R, Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E[], Arg, R>, arg?: Arg): Promise<R>;
- waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number }): Promise<void>;
+ waitForFunction<Arg, E extends SVGElement | HTMLElement = SVGElement | HTMLElement>(pageFunction: PageFunctionOn<E, Arg, any>, arg?: Arg, options?: { timeout?: number, signal?: AbortSignal }): Promise<void>;


What about other overrides here that have a timeout? I think these should get a signal as well.

i think there's many more missing, I'll do those chunked in follow-ups.

…erver-side

github-actions · 2026-06-30T11:55:43Z

Test results for "MCP"

3 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-chrome
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-firefox

7458 passed, 1132 skipped

Merge workflow run.

github-actions · 2026-06-30T12:00:16Z

Test results for "tests 1"

2 failed
❌ [chromium-library] › library/browsercontext-add-init-script.spec.ts:28 › should work without navigation, after all bindings @chromium-ubuntu-22.04-arm-node20
❌ [chromium-library] › library/browsercontext-expose-function.spec.ts:77 › should be callable from-inside addInitScript @chromium-ubuntu-22.04-arm-node20

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:476 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/video.spec.ts:717 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`

49217 passed, 1163 skipped

Merge workflow run.

This comment has been minimized.
Sign in to view

Simon Knott (Skn0tt) changed the title ~~feat(client): support AbortSignal on server-side methods~~feat: support AbortSignal on server-side methodsJun 4, 2026

Simon Knott (Skn0tt) requested a review from Dmitry Gozman (dgozman)June 4, 2026 16:31

Simon Knott (Skn0tt) commented Jun 5, 2026
View reviewed changes

Comment threadpackages/playwright-core/src/client/connection.ts

Simon Knott (Skn0tt) mentioned this pull request Jun 5, 2026
feat(expect): support AbortSignal on web-first assertions #41157
Closed

Dmitry Gozman (dgozman) reviewed Jun 5, 2026
View reviewed changes

Comment threaddocs/src/api/params.md Outdated
Comment threadpackages/playwright-core/src/client/page.ts Outdated

Simon Knott (Skn0tt) requested a review from Dmitry Gozman (dgozman)June 8, 2026 08:36

This comment has been minimized.
Sign in to view

Dmitry Gozman (dgozman) reviewed Jun 16, 2026
View reviewed changes

Simon Knott (Skn0tt)force-pushed the feat/abort-signal-server-side branch from a782655 to c7b916cCompare June 18, 2026 10:15

feat(core): support cancelling channel calls via AbortSignal
07a7b5c
Threads an AbortSignal through the client as a required second argument on channel methods (mirroring progress on the dispatcher side), so server-side calls can be cancelled.

Simon Knott (Skn0tt)force-pushed the feat/abort-signal-server-side branch from c7b916c to 07a7b5cCompare June 18, 2026 10:19

Simon Knott (Skn0tt) requested a review from Dmitry Gozman (dgozman)June 18, 2026 10:22

This comment has been minimized.
Sign in to view

Simon Knott (Skn0tt)force-pushed the feat/abort-signal-server-side branch from fe1c16f to 1b21b1dCompare June 18, 2026 13:18

This comment has been minimized.
Sign in to view

Merge upstream/main; support signal in Locator.waitForFunction
929307e

This comment has been minimized.
Sign in to view

Dmitry Gozman (dgozman) approved these changes Jun 30, 2026
View reviewed changes

Simon Knott (Skn0tt) added 3 commits June 30, 2026 13:16

Merge branch 'main' into feat/abort-signal-server-side
d83a22d

Merge remote-tracking branch 'upstream/main' into feat/abort-signal-s…
262e57b
…erver-side

ci
5b5f9e2

Simon Knott (Skn0tt) merged commit eb9eb48 into microsoft:mainJun 30, 2026
44 of 48 checks passed

This was referenced Jun 30, 2026
feat: support AbortSignal on more methods #41547
Merged
feat(elementhandle): add timeout and signal to inputValue #41548
Closed

Simon Knott (Skn0tt) mentioned this pull request Jul 9, 2026
chore(protocol): make timeout a protocol-level field #41712
Merged

Yusuke Iwaki (YusukeIwaki) mentioned this pull request Jul 31, 2026
[Ports]: Backport client side changes for 1.62 YusukeIwaki/playwright-ruby-client#389
Closed