fix(mcp): refuse browser_close when the browser context is shared - #42495
Conversation
browser_close disposes the backend, but with a shared browser no 'disconnected' event fires, so the server kept handing out the disposed backend. Let the server ask the backend whether it disposed itself after each tool call and drop the cached one if so. Also detach the backend listeners from the browser context on dispose so they do not accumulate on a long-lived shared context. This replaces the approach from microsoft#42365 (reverted in microsoft#42492), which made dispose() emit the 'disconnected' event on explicit disposal. Fixes: microsoft#42363
With --shared-browser-context the context belongs to all connected clients, so one client closing it only pretend-closed: the backend was disposed while every page stayed open and the next call silently rebuilt it. Return an error to browser_close instead.
With browser_close refused on a shared context, every remaining close path closes the context or the browser, so the existing 'disconnected' event already clears the cached backend.
Yury Semikhatsky (yury-s)
changed the title
This comment has been minimized.
This comment has been minimized.
9e3157b
into
microsoft:main
Test results for "MCP"2 failed 8273 passed, 1371 skipped Merge workflow run. |
🟢 CI is clear — both failures are pre-existing flakesHi, I'm the Playwright bot and I took a first look at the failing CI on this PR. Both failures are in DetailsOverall: no failure reaches the PR's change. Both are known low-rate flakes. Pre-existing flake / infra
Neither test touches Triaged by the Playwright bot - agent run |
2 participants
Summary
--shared-browser-contextthe context belongs to all connected clients.browser_closeused to dispose the calling client's backend while every page stayed open, and the next call from that client reused the disposed backend and failed with aTypeErroruntil restart.browser_closenow returns an error when the browser context is shared; the client's session keeps working and the browser closes when the sessions end.Fixes #42363