From TargetClosedError to a Native Edge Crash

Summary

• Playwright reported TargetClosedError while handling a download.
• Microsoft Edge had already terminated before download.save_as() failed.
• A new profile completed five downloads during its first browser process, but the failure appeared after reusing that profile across subsequent Edge processes.
• The initial application exception was therefore treated as a symptom. The investigation moved downward through Playwright, CDP transport, and the Edge process itself.

Initial signal

The investigation started with two log entries:

browser_disconnected reason=unexpected
Download.save_as: Target page, context or browser has been closed

Taken alone, these messages suggest a lifecycle problem in the application: the page may have been closed too early, or save_as() may have been called at the wrong time.

Process-level logging changed that interpretation. Edge exited before Playwright attempted to finish the save operation. The sequence was:

Edge process terminates
CDP connection closes
Browser, Context, and Page become unavailable
download.save_as() reports TargetClosedError

The Playwright exception was accurate, but it did not explain why the browser disappeared.

Components involved

Playwright’s launch_persistent_context() starts a browser against a specified user-data directory. This is useful when an automated workflow needs to retain cookies or local storage between runs.

• BrowserType.launch_persistent_context() — Playwright Python

That convenience also joins several layers into one API call: Playwright launches Edge, communicates through CDP, Edge performs the network request, and the operating system writes the downloaded file. A generic error at the API boundary can originate in any of those layers.

First reproduction pattern

The initial results appeared to implicate an existing profile:

The new profile result did not hold after restarting Edge:

New profile, first Edge process       -> five downloads succeed
Same profile, later Edge process      -> crash on the second or third launch

Multiple independently created profiles showed the same pattern. The meaningful condition was not simply whether a profile was old or new; it was whether the same profile state was reused by another Edge process.

Working hypotheses

At this stage, the plausible explanations included:

• corruption limited to the original profile;
• behavior specific to headless mode;
• an error caused by download.save_as();
• Playwright-specific browser arguments or CDP command ordering;
• a native failure within Edge.

The next tests changed one condition at a time. Successes and failures were recorded with the same environment, input file, and shutdown sequence wherever possible.

Test environment

The results in this series were observed on September 3, 2026.

These observations do not establish that every Edge 152 environment is affected. The responsible source component and the regression range were not identified at this point.

Next test

The next note tests the most visible alternatives: a newly created profile, headed versus headless operation, and download handling with and without save_as().

• Isolating Profile Reuse, Headless Mode, and save_as()