Redigera

Preview Runtime 156.0.4314.8 (Oct. 12, 2026)

Release notes for Microsoft Edge WebView2 Preview Runtime, release date: Oct. 12, 2026.

This is a Preview Runtime, for early testing. Prerelease testing of WebView2 SDKs uses a preview channel of Microsoft Edge (Beta, Dev, or Canary), which includes the WebView2 Preview Runtime.

These release notes are for the WebView2 Preview Runtime, which corresponds to the Beta preview channel of Microsoft Edge. We recommend testing your app using the Beta preview channel of Microsoft Edge, before these changes are promoted to Stable. If you want to test even earlier, you can test against Edge Dev or Edge Canary.

See Prerelease testing using preview channels of Microsoft Edge.

In addition to the following WebView2 Runtime improvements, you can also use the new web platform features from Microsoft Edge 156; see Microsoft Edge 156 web platform release notes (Oct. 22, 2026).

Upcoming breaking change: Removing the msAbydosHandwritingAttr WebView2 browser flag

Starting with v159, WebView2 will remove the deprecated msAbydosHandwritingAttr browser flag. After this change, passing msAbydosHandwritingAttr through WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS, registry-based browser arguments, or CoreWebView2EnvironmentOptions.AdditionalBrowserArguments will no longer enable the expected behavior.

Please review your app and test configuration, and plan accordingly.

What this means for your app

  • Apps that don't set msAbydosHandwritingAttr:

    No action required.

  • Apps or test tooling that set the msAbydosHandwritingAttr flag:

    Remove the msAbydosHandwritingAttr flag, and validate handwriting scenarios without it.

  • Enterprise deployments that configure browser arguments through environment variables or registry settings:

    Remove the msAbydosHandwritingAttr flag from managed configuration.

Learn more

Share feedback

Have a question, or encountered a regression? File an issue in the WebView2Feedback repository with your Runtime version, Windows version, configuration, and reproduction steps.

Upcoming breaking change: Required ACL setup for app-managed WebView2 Fixed Version runtimes on Windows

Starting with v159, WebView2 is strengthening the renderer sandbox for app-managed Fixed Version deployments. Applications that deploy and manage an unpackaged Fixed Version runtime must configure and preserve the required Windows access control list (ACL) entries on the runtime folder during installation, runtime updates, and repair.

This guidance applies to app-managed, unpackaged Fixed Version deployments on Windows 10 and Windows 11. Evergreen deployments and Windows-managed package folders do not require this installer action.

What this means for your app

  • Evergreen Runtime:

    No ACL action required for Microsoft-managed runtime files.

  • Packaged apps and Windows-managed package locations:

    Do not manually modify package-folder ACLs.

  • App-managed, unpackaged Fixed Version Runtime:

    Update your installer, updater, and repair flow to configure and verify the required permissions.

Required setup

Run the following commands from an appropriately elevated installer context, replacing {Fixed Version path} with the runtime folder that's deployed by your application:

icacls "{Fixed Version path}" /grant *S-1-15-2-2:(OI)(CI)(RX)

icacls "{Fixed Version path}" /grant *S-1-15-2-1:(OI)(CI)(RX)

These entries grant inheritable read-and-execute access to ALL RESTRICTED APPLICATION PACKAGES and ALL APPLICATION PACKAGES. Preserve the runtime folder's existing permissions.

How to prepare

  1. Add the ACL setup to installation, runtime update, and repair paths.

  2. After each deployment operation, verify that both identities have read-and-execute access on the runtime folder and its contents.

  3. Run the installed app as a normal user, and exercise every WebView2 feature that your app depends on. Initial page loading alone is not sufficient validation.

  4. Handle WebView2 process-start or access-denied failures with an actionable repair path.

  5. Do not use no-sandbox or another sandbox-disabling switch as a workaround.

Learn more

Share feedback

Have a question or encounter a deployment regression? File an issue in the WebView2Feedback repository with your deployment model, runtime path, Windows and Runtime versions, resulting ACLs, and reproduction steps.

Upcoming breaking change: Stricter File System Access directory checks

Starting with v159, WebView2 will apply stricter restricted-folder checks during File System Access directory traversal on Windows.

WebView2 on Windows will align more closely with Chromium security behavior by applying sensitive-location checks when web content accesses or enumerates entries beneath a granted directory.

This change can affect apps that expose the File System Access API to web content or delegate access to folders under protected system or profile locations. Please review your file-access design and plan accordingly.

Release timeline (tentative)

  • October 2026 — Advance announcement.

  • Migration window — Approximately 2 months after announcement; final dates are pending release-owner confirmation.

  • [Requires release-owner confirmation] — Stricter checks reach a WebView2 preview channel.

  • [Requires release-owner confirmation] — Enforcement reaches the Evergreen Stable Runtime and the corresponding Fixed Version release.

What this means for your app

  • Apps that don't use the File System Access API:

    No action required.

  • Apps that enumerate user-selected directories:

    Linked or protected child entries might now return an access-denied result.

  • Apps that intentionally access data beneath restricted locations:

    Direct File System Access workflows might stop working and require a storage or host-integration change.

  • Host-delegated workflows:

    Review whether the granted location, its children, or any linked targets fall under restricted-location policy.

How to prepare

  1. Move app-managed data required by web content to an appropriate non-restricted location, where possible.

  2. If protected data must remain in place, expose only the minimum necessary operations through a validated host-mediated interface, rather than broad, direct file-system access.

  3. Handle access-denied outcomes gracefully, and provide an actionable user recovery path.

About restricted folders

The restricted-location policy is security-sensitive and can evolve. Microsoft will not publish or guarantee an exhaustive directory list. Do not hard-code a folder list or assume that a location is allowed because it isn't named in documentation. Chromium's public guidance likewise describes restricted folders and examples, without publishing an exhaustive block list.

Learn more

  • Restricted folders in The File System Access API: simplifying access to local files, in Chrome docs.

Share feedback

Have a question or encounter a regression? File an issue in the WebView2Feedback repository with the API sequence, selected folder shape, linked-path details, Windows and Runtime versions, and reproduction steps.

Bug fixes

  • Restricted the DACL mutation surface.
  • Fixed failed Windows interactive logon attempt for the current local user.
  • Fixed an issue where WebResourceRequested events for service workers and shared workers weren't correctly scoped to the WebView2 profile.
  • Fixed the click propagation from the Window Controls Overlay (WCO) titlebar to webcontents.
  • Fixed incorrect viewport in minimal mode.
  • Fixed JAWS support in minimal window.
  • Fixed downloads to be submitted for antivirus scanning under the host app's identity instead of the shared runtime's.
  • Fixed Mark-of-the-Web prompt state so it is tracked per host app instead of per shared WebView2 runtime.

See also

  • Uppdaterades senast