You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Chromium/WebView2 – XSLT deprecation warning and ability to suppress the warning
#5742
We maintain a commercial WPF desktop application using Microsoft Edge WebView2 to render XML documents with associated XSLT stylesheets.
Our current implementation relies on the standard XML processing instruction:
The XML and XSLT files are stored locally in the same directory, and WebView2 currently performs the XSLT transformation and renders the resulting document correctly.
With recent Chromium/WebView2 versions, users now see the following warning:
This site uses XSLT; that functionality is being removed from this browser very soon. When that happens, this page will likely no longer display correctly.
Questions
Is there currently a supported WebView2 API, preference, command-line switch, or policy to suppress this specific XSLT deprecation warning?
Is there a WebView2-specific mechanism to continue using the built-in XSLT transformation temporarily while migrating to an alternative implementation?
What is the recommended migration path for desktop applications that currently depend on XML + XSLT client-side rendering?
Will XSLT removal in Chromium also apply to the WebView2 Runtime, and what is the expected timeline/runtime version for removal?
If native XSLT support is removed, is Microsoft recommending that applications perform the transformation themselves (for example, using a local XSLT processor) and provide the resulting HTML to WebView2?
We are specifically looking for a supported WebView2 solution, rather than asking end users to install an XSLT browser extension.
This is a desktop application distributed to many customers, so exposing a browser deprecation warning is undesirable, and we need a reliable migration path before XSLT support is removed.
Any guidance on the supported WebView2 configuration or recommended replacement architecture would be appreciated.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello,
We maintain a commercial WPF desktop application using Microsoft Edge WebView2 to render XML documents with associated XSLT stylesheets.
Our current implementation relies on the standard XML processing instruction:
The XML and XSLT files are stored locally in the same directory, and WebView2 currently performs the XSLT transformation and renders the resulting document correctly.
With recent Chromium/WebView2 versions, users now see the following warning:
This site uses XSLT; that functionality is being removed from this browser very soon. When that happens, this page will likely no longer display correctly.
We are aware of the Chromium XSLT deprecation/removal plan:
https://chromestatus.com/feature/4709671889534976
Questions
Is there currently a supported WebView2 API, preference, command-line switch, or policy to suppress this specific XSLT deprecation warning?
Is there a WebView2-specific mechanism to continue using the built-in XSLT transformation temporarily while migrating to an alternative implementation?
What is the recommended migration path for desktop applications that currently depend on XML + XSLT client-side rendering?
Will XSLT removal in Chromium also apply to the WebView2 Runtime, and what is the expected timeline/runtime version for removal?
If native XSLT support is removed, is Microsoft recommending that applications perform the transformation themselves (for example, using a local XSLT processor) and provide the resulting HTML to WebView2?
We are specifically looking for a supported WebView2 solution, rather than asking end users to install an XSLT browser extension.
This is a desktop application distributed to many customers, so exposing a browser deprecation warning is undesirable, and we need a reliable migration path before XSLT support is removed.
Any guidance on the supported WebView2 configuration or recommended replacement architecture would be appreciated.
All reactions