I'm not sure where to direct this message, hopefully this is not too far wrong.
I'm trying to test how an enterprise Android app that uses the Cordova framework will behave once XSLT is deprecated/removed from the Android System WebView. We need to be able to get ahead of the expected deprecation in November, since our customers' devices allow Google Play Store to update the System WebView. Our current plan is to use the polyfill, for minimum change. I haven't been able to disable the built-in XSLTProcessor to test that this works. I have tried Android System WebView Beta v151.0 (matching the release version) and Dev v155.0. Neither showed the expected behaviour of XSLT processing being disabled: `new XSLTProcessor()` created an object, and calling `importStylesheet` and `transformToFragment` both worked as we would normally expect. The deprecation warning appeared in the console but the feature still worked. I've also tried using the TestDPC app's Managed Configurations feature to set the XSLTEnabled flag to false, without success. We use XSLTProcessor to transform product data in XML format with stylesheets that generate printer description languages (e.g. Zebra CPCL or ZPL-II), for printing labels. It's very much a case of path dependence: I wouldn't start from here, but here is where we are. Since this is an app with a long history, we are still loading the app assets from `file://` URLs, using Cordova's `AndroidInsecureFileModeEnabled` option. Setting this flag causes Cordova to call `WebSettings.setAllowFileAccess(true)` and `WebSettings.setAllowUniversalAccessFromFileURLs(true)`. This is so that local storage data from previous versions of the app can be read. Most of the app's data is in SQLite files, but critical configuration data is in local storage. -- Mike Dimmick Lead Software Engineer, M-Netics Retail HHT Peak Technologies Ltd On Friday, June 26, 2026 at 10:09:03 PM UTC+1 Chris Harrelson wrote: > LGTM > > On Fri, Jun 26, 2026 at 2:01 PM Mason Freed <[email protected]> wrote: > >> Standard template below. But note that this is a request for a deprecation >> trial >> <https://developer.chrome.com/docs/web-platform/chrome-deprecation#:~:text=default%20from%20Chrome.-,Deprecation%20trial,-This%20is%20a>, >> >> starting M152 and going until M175. That's inline with the posted >> timeline >> <https://developer.chrome.com/docs/web-platform/deprecating-xslt#timeline_for_chrome>, >> >> allowing affected sites plenty of extra time to migrate away from XSLT, in >> case they cannot migrate before the feature is disabled by default in M158 >> (Nov, 2026). Also note that this deprecation trial is being requested >> several milestones early to allow plenty of time to test before the feature >> is disabled. >> >> ----- >> *Contact emails* >> [email protected] >> >> *Explainer* >> *No information provided* >> >> *Specification* >> *No information provided* >> >> *Design docs* >> *No information provided* >> https://github.com/whatwg/html/issues/11523 >> >> *Summary* >> [XSLT v1.0](https://www.w3.org/TR/xslt-10/), which all browsers adhere >> to, was standardized in 1999. In the meantime, XSLT has evolved to v2.0 and >> v3.0, adding features, and growing apart from the old version frozen into >> browsers. This lack of advancement, coupled with the rise of JavaScript >> libraries and frameworks that offer more flexible and powerful DOM >> manipulation, has led to a significant decline in the use of client-side >> XSLT. Its role within the web browser has been largely superseded by >> JavaScript-based technologies, such as JSON and React. Chromium uses the >> **libxslt** library to process these transformations, and [libxslt was >> unmaintained]( >> https://discourse.gnome.org/t/stepping-down-as-libxslt-maintainer/27615) >> for ~6 months of 2025. Libxslt is a complex, aging C codebase of the type >> notoriously susceptible to memory safety vulnerabilities like buffer >> overflows, which can lead to arbitrary code execution. Because client-side >> XSLT is now a niche, rarely-used feature, these libraries receive far less >> maintenance and security scrutiny than core JavaScript engines, yet they >> represent a direct, potent attack surface for processing untrusted web >> content. Indeed, XSLT is the source of several recent high-profile security >> exploits that continue to put browser users at risk. For these reasons, >> Chromium (along with both other browser engines) plans to deprecate and >> remove XSLT from the web platform. For more details, see this [Chrome for >> Developers article]( >> https://developer.chrome.com/docs/web-platform/deprecating-xslt). >> >> *Blink component* >> Blink>XML >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EXML%22> >> >> *Web Feature ID* >> xslt <https://webstatus.dev/features/xslt> >> >> *TAG review* >> *No information provided* >> >> *TAG review status* >> Not applicable >> >> *Goals for experimentation* >> The tentative deprecation/removal plan would be as follows: - M142 (Oct >> 28, 2025): Early warning console messages added to Chrome. - M143 (Dec 2, >> 2025): Official deprecation of the API - deprecation warning messages begin >> to show in the console and in lighthouse. - M148 (March 10, 2026 Canary): >> Canary, Dev, and Beta releases begin disabling XSLT by default, as an >> early-warning. - M152 (Aug 25, 2026): Origin Trial (OT) and Enterprise >> Policy (EP) go live for testing. These allow sites and enterprises to >> continue using features past the removal date. - M158 (Nov 17, 2026): XSLT >> stops functioning on Stable releases, for all users other than Origin Trial >> and Enterprise Policy participants. - M176 (Aug 17, 2027): Origin Trial and >> Enterprise Policy stop functioning. XSLT is disabled for all users. >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> Removal of this feature constitutes a compat risk, since sites that use >> XSLT will stop working when the feature is removed. Mitigations include a >> very long deprecation window, a polyfill, lots of outreach, and both origin >> trials and enterprise policies to allow sites even more time to migrate. >> The polyfill (https://github.com/mfreed7/xslt_polyfill) is specifically >> built to mimic the existing behavior of Chrome as closely as possible. In >> most cases, it is a single-line drop-in fix for a lack of XSLT in the >> browser. According to my analysis, about 75% of sites that hit the use >> counter don't appear to be visibly broken. Of the 25% that do appear broken >> in some way (e.g. some components not rendering, or raw XML output instead >> of transformed HTML), 82% have their functionality restored by the addition >> of the polyfill. Of the 18% that can't use the polyfill, the primary reason >> seems to be CORS restrictions, as detailed in the polyfill documentation. >> And even if site owners take no action, individual users can install the >> browser extension(https://github.com/mfreed7/xslt_extension), which uses >> the polyfill, to get back full functionality. >> >> *Gecko*: Positive ( >> https://github.com/whatwg/html/issues/11523#issuecomment-3149788558) >> >> *WebKit*: Positive ( >> https://github.com/whatwg/html/issues/11523#issuecomment-3149280766) >> >> *Web developers*: Negative ( >> https://github.com/whatwg/html/issues/11523#issuecomment-3150969971) >> Existing >> users of XSLT are understandably negative on this removal, and have been >> very vocal about it on the standards issue and elsewhere. There are also >> mixed/positive reactions from some folks in the public discussions, who >> seem to agree with the removal of XSLT from browsers. But the >> average/overall developer opinion (as measured by comments on public >> threads) is negative. Various public discussions: - >> https://news.ycombinator.com/item?id=44952185 - >> https://www.reddit.com/r/programming/comments/1mxdm22/xslt_removal_will_break_multiple_government_and/ >> - https://news.ycombinator.com/item?id=44987346 - >> https://news.ycombinator.com/item?id=44987552 - >> https://news.ycombinator.com/item?id=44987239 - >> https://news.ycombinator.com/item?id=44909599 >> >> *Other signals*: >> >> *Activation* >> See above - the polyfill and extension will ease the migration burden. >> >> *Security* >> This removal constitutes a big win for security, in that it removes a >> highly-vulnerable external library from Chromium. >> >> *WebView application risks* >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> In the same way that this poses a compat risk on the open web, it poses a >> risk for WebView applications. >> >> >> *Ongoing technical constraints* >> *No information provided* >> >> *Debuggability* >> *No information provided* >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?* >> Yes >> >> *Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> Yes >> These tests verify the functionality of XSLT. They will need to be >> changed/removed: https://wpt.fyi/results/dom/xslt >> >> *Flag name on about://flags* >> XSLT >> >> *Finch feature name* >> XSLT >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://crbug.com/435623334 >> >> *Estimated milestones* >> Origin trial desktop first 152 >> Origin trial desktop last 175 >> DevTrial on desktop 143 >> Origin trial Android first 152 >> Origin trial Android last 175 >> DevTrial on Android 143 >> Origin trial WebView first 152 >> Origin trial WebView last 175 >> Rollout step 1 176 >> Rollout step 2 143 >> Rollout step 3 152 >> Rollout step 4 158 >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/4709671889534976?gate=5148216907661312 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhO%3D2mNq8QyzU5Ah9z8FR6pO9tct9G_prKD6bdtAE7cwA%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhO%3D2mNq8QyzU5Ah9z8FR6pO9tct9G_prKD6bdtAE7cwA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e8e31116-b463-43f7-af0e-2cca48c48c02n%40chromium.org.
