test(webview): add a timeout for `clearCookies` in teardown so a busy page can't stall it by dcrousso · Pull Request #41416 · microsoft/playwright

dcrousso · 2026-06-23T01:43:39Z

tests/page/page-set-content.spec.ts:153:3 › should handle timeout properly will infinitely loop the page

as a result, none of the WebKit inspector protocol messages are handled

context.clearCookies performs multiple round-trips using the WebKit inspector protocol (Page.getCookies and then Page.deleteCookie for each)

as such, give the page fixture a timeout so that if clearCookies hangs then the worker will be killed and restarted instead of waiting forever

pavelfeldman · 2026-06-23T02:48:54Z

    // The shared Mobile Safari cookie store persists across tests; clear it
    // while still on the test's domain (webview cookies are domain-scoped).
-    await page.context().clearCookies().catch(() => {});
+    await Promise.race([


Sounds like the fix should be in clearCookies()

pavelfeldman · 2026-06-23T18:56:01Z

-      cookieName: c.name,
-      url: `${c.secure ? 'https' : 'http'}://${c.domain.replace(/^\./, '')}${c.path}`,
-    })));
+    await raceAgainstDeadline(async () => {


This is still unexpected - it looks like page.deleteCookies can stall when user calls it?

raceAgainstDeadline does a Promise.race with a setTimeout so this should never take more than 5s

also, WVPage.prototype.deleteCookies is not exposed to clients

the only thing clients can invoke is BrowserContext.prototype.clearCookies, which eventually routes to here

if the concern is about somewhere else in playwright using WVPage.prototype.deleteCookies (or WVPage.prototype.getCookies) then yeah i can move the raceAgainstDeadline to be there instead

Ah, we should rename this page to wvPage to make it clear it is not the one from the page.

Look for "await progress.race(this._context.clearCookies({" and instead of racing externally, plumb the progress as the first argument into the call chain, all the way to WVPage.prototype.deleteCookies, where you will race the protocol call with the progress.

digging into this a bit more, we actually already have a progress.race(...) inside browserContextDispatcher.clearCookies, which should handle all browsers and platforms, so i dont think we need/want another one here just for iOS

circling back, this fix was just about trying to solve some test timeouts that happened as a result of us attempting to ensure cookies are cleared at the end of each test run

as such, it should only ever affect developers if their test involves infinitely busying the page such that no inspector protocol messages can be received (which is also what one of our tests does)

the only reason we're having issues is because we're using a lower-level clearCookies than what all other developers could use

im happy to move the progress.race(...) to a lower level if you feel that's preferred, but it would be a different approach to almost all other commands

I'm lost as to what we are doing here then. Will failing to delete cookies result in error? Should it respect a given timeout that comes with the call?

the original fix i had in this PR modified the test harness to only wait for this lower-level clearCookies for 5s in the teardown after a test run finishes (i.e. there's no timeout)

ultimately i think the question we need to answer is "should it be considered a test failure if the page is left in a state that we can no longer communicate with it after the test is over?"

if yes then we should close the PR as that's the intended behavior

if no then we could probably use any previously set timeout as a limit on the lower-level clearCookies so that we give it as much time as possible to work while ensuring that it doesn't exceed the overall time limit

If we can no longer communicate with the page, this test has failed and we should shut down the worker altogether.

pavelfeldman · 2026-06-25T17:37:47Z

-    // The shared Mobile Safari cookie store persists across tests; clear it
-    // while still on the test's domain (webview cookies are domain-scoped).
-    await page.context().clearCookies().catch(() => {});
+    // The shared Mobile Safari cookie store persists across tests; clear it while


I am not sure I follow: this does not clear any tests, does not do proper cleanup for all the visited origins either. If there is a clean way to implement it (reset for reuse-alike), let's do it. Otherwise, let's not add this code.

unless something has otherwise changed, tests/page/page-set-content.spec.ts:153:3 › should handle timeout properly is a frequent timeout failure when running tests

so yes this does not enable any previously skipped tests, but it does fix a (previously) known flaky test

I'd rather say it masks an issue. Why not a proper fix?

that's definitely a fair way of looking at it

something i think is worth mentioning tho is that tests/page/page-set-content.spec.ts:153:3 › should handle timeout properly DELIBERATELY causes the page to hang with the goal of verifying that the client API timeout mechanism works correctly

to make matters worse, because we're trying to share a single iOS simulator for all of this, that busy page now has no way to recover

ill try looking into detecting when the page is hung and tearing down MobileSafari and/or the iOS Simulator in that case

… page can't stall it `tests/page/page-set-content.spec.ts:153:3 › should handle timeout properly` will infinitely loop the page as a result, none of the WebKit inspector protocol messages are handled `context.clearCookies` performs multiple round-trips using the WebKit inspector protocol (`Page.getCookies` and then `Page.deleteCookie` for each) as such, give the page fixture a `timeout` so that if `clearCookies` hangs then the worker will be killed and restarted instead of waiting forever

github-actions · 2026-06-30T01:19:13Z

Test results for "MCP"

6 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [chromium] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chromium
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-firefox
❌ [firefox] › mcp/annotate.spec.ts:173 › user-initiated annotate downloads zip with feedback.md @mcp-macos-latest-firefox
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-firefox
❌ [webkit] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-webkit

7455 passed, 1132 skipped

Merge workflow run.

github-actions · 2026-06-30T01:26:45Z

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

1 flaky

⚠️ [playwright-test] › ui-mode-test-output.spec.ts:118 › should collapse repeated console messages for test `@windows-latest-node22`

49170 passed, 1163 skipped

Merge workflow run.

dcrousso requested review from pavelfeldman and yury-s June 23, 2026 01:43

This was referenced Jun 23, 2026

feat(webview): implement cookie support #41393

Merged

fix(webview): adjust UserAgent test to work with mobile #41415

Merged

fix(webview): send Target.setPauseOnStart earlier #41413

Merged

feat(webview): track same-document navigations #41414

Merged

This comment has been minimized.

Sign in to view

pavelfeldman reviewed Jun 23, 2026

View reviewed changes

dcrousso force-pushed the fix-WKWebView-page-timeout branch from 9392db6 to 1f976f6 Compare June 23, 2026 17:10

This comment has been minimized.

Sign in to view

dcrousso requested a review from pavelfeldman June 23, 2026 18:48

pavelfeldman reviewed Jun 23, 2026

View reviewed changes

dcrousso requested a review from pavelfeldman June 23, 2026 19:32

dcrousso force-pushed the fix-WKWebView-page-timeout branch from 1f976f6 to 2833926 Compare June 25, 2026 01:54

This comment has been minimized.

Sign in to view

pavelfeldman reviewed Jun 25, 2026

View reviewed changes

dcrousso force-pushed the fix-WKWebView-page-timeout branch from 2833926 to 6caf0c0 Compare June 30, 2026 00:45

dcrousso requested a review from pavelfeldman June 30, 2026 00:46

yury-s approved these changes Jun 30, 2026

View reviewed changes

dcrousso merged commit 5eab646 into microsoft:main Jun 30, 2026
54 of 64 checks passed

dcrousso deleted the fix-WKWebView-page-timeout branch June 30, 2026 23:13

Uh oh!

Conversation

dcrousso commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 30, 2026

Test results for "MCP"

Uh oh!

github-actions Bot commented Jun 30, 2026

Test results for "tests 1"

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dcrousso commented Jun 23, 2026 •

edited

Loading