takeSnapshot throws "Execution context was destroyed" due to about:blank iframes created by its own archiving process

[mbouchardC3]

Describe the bug
Calling takeSnapshot mid-test intermittently throws the following error:
Error: proxy.evaluate: Execution context was destroyed, most likely because of a navigation.
at takeSnapshot (.../node_modules/@chromatic-com/playwright/dist/index.js:18:49598)
By attaching frameattached and framenavigated listeners to the page, we confirmed that takeSnapshot itself is creating about:blank iframes as part of its DOM archiving process. The navigation events fired by those iframes destroy the execution context that takeSnapshot's own page.evaluate() is running in, causing it to crash itself. The main frame never navigates — the issue is entirely self-inflicted by takeSnapshot's internals.
Additionally, the number of iframes created grows with each retry (1 on the first call, 2 on the second, 3 on the third, etc.), meaning retrying makes the problem progressively worse.

To Reproduce

1. Set up a Playwright test using @chromatic-com/playwright
2. Navigate to a page that has any background activity (polling, websockets, periodic re-renders, etc.)
3. Perform an action that triggers a data reload (e.g. applying a filter on a grid)
4. Call takeSnapshot(page, 'my-snapshot', testInfo) immediately after
5. See the error above

Expected behavior
takeSnapshot should complete successfully regardless of the about:blank iframes it creates internally. Its own iframe lifecycle should not be able to destroy its own page.evaluate() execution context.

Screenshots
Logs confirming the iframes are created by takeSnapshot itself, not the application:
[FRAME] Existing frame 0: https://
[SNAPSHOT] About to take snapshot at 1775770090272
[FRAME ATTACHED] at 1775770090300
[NAV] Frame navigated - isMain: false, url: about:blank at 1775770090301
[FRAME ATTACHED] at 1775770090308
[NAV] Frame navigated - isMain: false, url: about:blank at 1775770090309

[SNAPSHOT] About to take snapshot at 1775770093321
[FRAME ATTACHED] at 1775770093335
[FRAME ATTACHED] at 1775770093335
[NAV] Frame navigated - isMain: false, url: about:blank at 1775770093336
[NAV] Frame navigated - isMain: false, url: about:blank at 1775770093336

Additional context
@chromatic-com/playwright: 0.12.8
@playwright/test: 1.59.1
Browser: Chromium
This issue does not occur with percySnapshot, which uses page.screenshot() and has no execution context dependency
Attempted workarounds (route blocking, CDP lifecycle events, retries) all fail because the context is destroyed by takeSnapshot's own iframe creation, not by anything the application does

[mbouchardC3]

Additional investigation — client-side workaround attempts
After confirming the bug, we attempted every possible client-side workaround to intercept or work around the context destruction. All attempts failed.

1. DOM state logging before takeSnapshot
   We added logging to capture the page state immediately before each takeSnapshot call. Results consistently showed:
   readyState: complete
   1 active frame
   No loading indicator (on first call)
   The page was fully stable before takeSnapshot was called, confirming the crash is triggered entirely from within takeSnapshot itself.

2. Patching page.evaluate
   Attempted to monkey-patch page.evaluate to retry on context destruction. Failed because aPage is a Playwright Proxy object — patching the surface method does not reach the actual internal call path.

3. Patching _channel._callHandler
   Logged all methods on _channel and patched _callHandler on the prototype. The patch was hit successfully, but evaluate never appeared as a command — takeSnapshot routes its evaluate call through a different internal path entirely.

4. Patching frame _callHandler
   Moved the patch to _mainFrame._channel's prototype. Same result — evaluate never appeared. However, this logging revealed the exact repeating pattern causing the crash:
   frameAttached → loadstate → loadstate → navigated → loadstate → loadstate → frameDetached

5. Suppressing navigated, frameAttached, frameDetached
   Attempted to suppress these events in the frame's _callHandler to prevent context destruction. The suppression worked at the Playwright level (confirmed via logs), but the context was still destroyed — proving the destruction happens at the CDP/browser level, beneath any Playwright interception point.

6. Retry loop
   Wrapped takeSnapshot in a retry loop (up to 5 attempts). This made things worse — the number of about:blank iframes created grew with each retry (1 on attempt 1, 2 on attempt 2, etc.), progressively increasing instability.

7. Waiting for loading indicator
   Added logging across all retry attempts and discovered that takeSnapshot's own iframe creation triggers the DevEx grid's loading indicator. This creates an unbreakable cycle:
   takeSnapshot starts → creates about:blank iframes → grid loading indicator appears → context destroyed → retry → iframes recreated → loading indicator reappears immediately → repeat indefinitely
   The loading indicator never disappears because takeSnapshot itself is what causes it to appear.

8. CSS injection
   Attempted to force-hide the loading indicator via addStyleTag before calling takeSnapshot. Had no effect on the crash since the root cause is the CDP context destruction, not the loading indicator itself.

Conclusion:
The context destruction occurs at the CDP/browser level, triggered by takeSnapshot's own internal iframe creation. There is no accessible interception point from outside takeSnapshot. A fix must come from within takeSnapshot itself — specifically, its iframe archiving process must be isolated from the host page's execution context.

[mbouchardC3]

I'll be waiting for a response on your side. I am currently migrating our company's visual test projects from Percy to Chromatic and this issue is a blocker for us

[skitterm]

@mbouchardC3 thanks for the details and investigation. We'll look this over and will get back to you within the next week!