Edit

SDK 1.0.4255-prerelease, for Runtime 154 (Sep. 11, 2026)

Release notes for Microsoft Edge WebView2 Prerelease SDK, release date: Sep. 3, 2026.

NuGet package for WebView2 SDK 1.0.4255-prerelease

For full API compatibility, this Prerelease version of the WebView2 SDK requires the WebView2 Runtime that ships with Microsoft Edge version 154.0.4255.0 or later; see Preview Runtime 154.0.4258.9 (Sep. 10, 2026).

Detailed contents:

Experimental APIs (Phase 1: Experimental in Prerelease)

The following APIs are in Phase 1: Experimental in Prerelease, and have been added in this Prerelease SDK.

Frame-level LaunchingExternalUriScheme API

The LaunchingExternalUriScheme event is now also raised on CoreWebView2Frame, in addition to CoreWebView2. This lets a host attribute an external-URI-scheme launch (such as mailto:, tel:, or a custom protocol) to the specific iframe that initiated it. This is useful when multiple sub-apps are hosted in iframes, including when iframes share the same origin.

The LaunchingExternalUriScheme event is raised when content in a frame, or in an iframe nested within it, attempts to launch an external URI scheme. When the launch originates from a nested iframe, the event bubbles outward through the tracked CoreWebView2Frame ancestors — starting with the closest (innermost) tracked frame, and proceeding toward the top-level frame — and finally to CoreWebView2. The event sender for each invocation is the CoreWebView2Frame receiving the event.

CoreWebView2LaunchingExternalUriSchemeEventArgs has a new Handled property. Frame-level handlers are invoked before the CoreWebView2-level handlers; if a frame-level handler sets Handled to TRUE, the event is not raised on the remaining ancestor frames or on CoreWebView2. Cancel continues to control whether the URI is launched, while Handled controls whether the remaining handlers are invoked. Args (including Cancel and Handled) are shared across tiers; to suppress the WebView-level handlers when taking a Deferral, set Handled before taking the deferral.

Shared Cluster Environment API

The Shared Cluster Environment API lets cooperating host applications explicitly share a WebView2 environment, including one browser process and one user data folder, by agreeing on a ClusterName. Applications don't supply a user data folder path; the WebView2 Runtime derives it from the cluster name.

A host app calls CoreWebView2Environment.CreateOrJoinClusterEnvironmentAsync with a CoreWebView2ClusterEnvironmentOptions instance. The first host to establish the cluster determines its process-wide options. Later hosts join when their options match. These options remain authoritative for as long as the shared browser process is running; after it exits, the next host can establish the cluster with different options.

The above operation returns a CoreWebView2ClusterEnvironmentCreateResult containing a Status and, on success, the shared CoreWebView2Environment. Possible values of Status:

  • Succeeded indicates success. A shared CoreWebView2Environment is created and returned.

  • OptionsMismatch indicates that a running cluster has different options. A shared CoreWebView2Environment isn't created and returned.

  • NotSupported indicates that the host cannot use cluster environments, such as a sandboxed AppContainer process. A shared CoreWebView2Environment isn't created and returned.

Failures to start or complete the operation are reported separately as exceptions in .NET and WinRT, or failing HRESULT return values in Win32.

Call CoreWebView2Environment.GetClusterEnvironmentOptions to read a running cluster's options without launching a browser. It returns null when no cluster is running or the host cannot use cluster environments. The recommended flow is to read the current options, reuse them if available, and then create or join. Because another host can establish a cluster between these calls, applications must still handle OptionsMismatch by reading the options again and retrying, or by using a private environment.

PerHostProfileIsolation is enabled by default and namespaces profile names per host application to prevent accidental profile sharing. This isn't a security boundary; cluster members must trust one another. Sharing is supported within the same user and logon session, with hosts using the same integrity level, elevation state, and resolved WebView2 Runtime. Applications should check runtime support and fall back to a private environment when the API is unavailable.

See the Shared WebView2 Cluster Environment API specification.

See also

  • Last updated on