NewWindowRequested-assigned CoreWebView2: first navigation canceled by browser (ERR_ABORTED, canceled=true) within ms, on a fresh popup, no WebResourceRequested, no window.close()

Environment

• Microsoft.Web.WebView2 SDK: 1.0.4078.44
• App: WPF (.NET), self-hosted CoreWebView2 popups via NewWindowRequested
• OS: Windows 11

Repro shape

The app hosts window.open()-created popups in-app rather than letting WebView2 open its own popup
window: in NewWindowRequested, we create a new native window + a new CoreWebView2 in the same
CoreWebView2Environment/profile as the opener (EnsureCoreWebView2Async(existingEnv)), wire event
handlers, then set e.NewWindow = core (never e.Handled) and complete the deferral in finally.
This matches the pattern in Microsoft's own WebView2WpfBrowser sample.

var deferral = e.GetDeferral();
try
{
    popup = new SomeWindow();
    popup.Show();
    await popup.Browser.EnsureCoreWebView2Async(existingEnvironment);

    var core = popup.Browser.CoreWebView2;
    core.WindowCloseRequested += (_, _) => popup.Close();
    // ... other event wiring ...
    e.NewWindow = core;
}
finally { deferral.Complete(); }

Symptom

Against one specific site (a legacy enterprise SSO/web-admin app opening a small named popup,
window.open(url, "History", "width=185,height=298")), the popup's first-ever navigation, on
the first-ever click of a fresh app session (not a repeat/reused-window case), is canceled by the
browser itself almost immediately:

NavigationStarting uri=<target>                                    userInitiated=True redirected=False
CDP Network.requestWillBeSent requestId=<id> method=GET type=Document hasUserGesture=true uri=<target>
CDP Network.loadingFailed    requestId=<id> type=Document errorText=net::ERR_ABORTED canceled=true blockedReason=
NavigationCompleted success=False httpStatus=0 webError=ConnectionAborted

requestWillBeSent and loadingFailed share the same CDP requestId and are ~4-7ms apart — this
is the same request dying almost instantly, not two requests being conflated.

What's been ruled out

• Not a reused/stale named window: confirmed via repeated testing that this happens on the very
  first click of a fresh session every time, not only on a repeat click of the same window.open
  name.
• Not WebResourceRequested/WebResourceResponseReceived never firing due to subscription order:
  confirmed these are subscribed after e.NewWindow = core, per the documented remark on
  CoreWebView2.WebResourceRequested ("If this event is subscribed in the NewWindowRequested handler
  it should be called after the new window is set"). They still never fire — CDP is the only layer
  that sees the request at all.
• Not the page calling window.close(): WindowCloseRequested is wired and logged; it never
  fires before or during the cancel.
• Not a silently-failing AddWebResourceRequestedFilter call: the filter registration is logged
  on failure; no failure is ever logged.
• Not a code-level deviation from the official sample: line-by-line comparison against
  WebView2Samples/SampleApps/WebView2WpfBrowser/MainWindow.xaml.cs's NewWindowRequested handling
  found no meaningful difference from our implementation.
• Not something specific to real Edge: the same site's same popup, opened in a normal (non-WebView2-hosted)
  Edge browser window, opens successfully every time with no visible failure.

What this looks like

The request is genuinely built and handed to the network stack (CDP sees it), then canceled by the
browser itself (canceled=true, no blockedReason) within single-digit milliseconds, for a reason
that isn't in the host app's code and isn't the page's own script closing the window. This is on a
freshly-created CoreWebView2 assigned as NewWindow in response to NewWindowRequested.

Possibly related

• #4250 (NewWindowRequested handling regressed 114→120+, e.Handled=true + reused-webview
  scenario) — different mechanism (we always create a brand-new CoreWebView2), but same API
  surface and same general class of symptom (a NewWindowRequested-driven popup not behaving as
  expected).
• #1144 (window.chrome.webview never initialized on a NewWindowRequested-created _blank
  window) — different symptom, same API surface.

Neither matches this symptom exactly (immediate browser-side cancel of the very first navigation),
so filing this as a distinct report rather than a comment on either.

Question

Is there a known reason a NewWindowRequested-assigned CoreWebView2's first navigation can be
canceled by the browser itself (net::ERR_ABORTED, canceled=true, no blockedReason) within a
few milliseconds of NavigationStarting, with zero WebResourceRequested and no page-initiated
window.close()? Any known interaction between environment/profile reuse across the opener and a
brand-new popup CoreWebView2, or between the deferred NewWindow assignment and the underlying
Chromium navigation lifecycle, that would produce this?

Happy to provide a minimal repro app if useful — the triggering site is an internal enterprise
SSO/web-admin tool I can't share directly, but the popup-hosting code above is the complete
relevant surface.

Start with WebView2Samples/SampleApps/WebView2WpfBrowser/MainWindow.xaml.cs and its NewWindowRequested handling, then compare the deferred NewWindow assignment and event wiring with the CDP requestWillBeSent/loadingFailed trace. A useful result would be a minimal reproducible app or a documented lifecycle condition that explains the first-navigation cancellation without relying on the unavailable enterprise site.