Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Release notes for Microsoft Edge WebView2 Runtime, release date: Jul. 7, 2026.
WebView2 Runtime is changing to a 2-week release cadence
Starting with version 152 (Aug. 24, 2026), the WebView2 Runtime moves to a 2-week release cadence. This is aligned with Microsoft Edge. WebView2 Runtime version 151 is the final release that's on a 4-week release cadence.
See [Announcement] WebView2 Runtime moves to a 2-week release cadence (starting v152).
Bug fixes
Fixed the reentrancy for frame deletion.
Fixed object wrapper access for a User Authorization File (UAF).
Stamped the browser-authoritative origin on the host pipe, to prevent a
WebMessageReceivedEventArgs.Sourcespoof.Restricted the access to a singleton host pipe, in a deprecated WebView2.
Removed the
originparameter from methods that access a native object.Hardened WebView2 virtual-host
kDenyenforcement against renderer spoofing and New Technology File System (NTFS)-junction escapes.Fixed the window-to-visual UI Automation (UIA) tree.
Fixed a regression in the
AddScriptToExecuteOnDocumentCreatedAPI.Added total-count histograms for WebView2 environment and controller creation attempts.
Mapped
TERMINATION_STATUS_LAUNCH_FAILED_OS_POLICYtokLaunchFailed.Updated the failure reason classification to
OOM, for a process that's been killed to reclaim memory.Added a system memory snapshot at out-of-memory (OOM) detection time for analysis.
Fixed the silent closing of a popup, when the host expects the popup to remain open.
Added trusted origin check during host object access.
Reduced redundant map lookups in WebView2 URL request manager, for improved performance.
Eliminated unnecessary string allocations in WebView2 cookie layer, for improved performance.
Breaking change: Enable Windows shell handwriting support for WebView2 in WindowToVisual mode
WebView2 is introducing support for Windows shell handwriting (pen handwriting-to-text) for edit fields inside WebView2 instances that are hosted in Window to Visual (WindowToVisual) mode on Windows.
This change affects only WindowToVisual hosting mode. WindowToWindow hosting mode already supports Windows shell handwriting, and VisualToVisual hosting mode isn't supported by this change.
Before this change: WebView2 in WindowToVisual mode doesn't register an ITfHandwritingSink on the Text Services Framework (TSF) thread. Windows shell handwriting can still work, but handwriting target determination uses the OS UI Automation (UIA)-based path.
After this change: If the msAbydosForWindowlessWV2 feature flag is disabled, the behavior remains the same as before this change, including the UIA-based handwriting target determination path.
If the msAbydosForWindowlessWV2 feature flag is enabled, WebView2 in WindowToVisual mode registers a per-instance ITfHandwritingSink on the TSF thread. This enables Windows shell handwriting for edit fields inside WebView2, and changes how TSF handwriting events are routed on the shared TSF thread.
If your app already registers its own ITfHandwritingSink on its TSF thread, pen handwriting will continue to work for your app's native edit fields, and pen handwriting will also work inside WebView2 edit fields.
If your app doesn't register its own ITfHandwritingSink, pen handwriting may stop working for your app's native edit fields after this change is enabled by default. This occurs because WebView2 returns E_NOTIMPL for HWNDs that it doesn't own, expecting TSF to chain to another registered sink. If no host sink is registered, TSF doesn't fall back to the default UIA-based handwriting target resolution.
To preserve pen handwriting support for your app's native edit fields, register your own ITfHandwritingSink on the TSF thread. Pen handwriting inside WebView2 edit fields is enabled automatically by this change.
You can proactively validate your WebView2 app's behavior by enabling the following feature flag before launching your app:
set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--enable-features=msAbydosForWindowlessWV2
In releases 149 and 150, the msAbydosForWindowlessWV2 feature flag is disabled by default, giving apps time to proactively test. Starting in release 151, the feature is planned to be enabled by default.
By testing your WebView2 app with this feature flag enabled, you can identify whether any native edit-field handwriting workflows in your app depend on registering a host ITfHandwritingSink.
See also:
- [Breaking Change] Enabling Windows ShellHandwriting Support for WebView2 in WindowToVisual Mode (Issue #134)
- Windowed vs. Visual hosting of WebView2
- WebView2 browser flags - the
msAbydosForWindowlessWV2feature flag.