Intent to Unship: XSLT

[Andreas Farre]

Summary:
As has been described through other channels, XSLT is a rarely-used feature with a track record of being the source of many security issues. Most of its features have been directly superseded by other web platform functionality, and it’s lingering at a sub 0.1% use count. There are of course risks with removing a web feature but the arguments that the benefits outweigh the risk is exceptionally strong. For web developers, an option to mitigate breakage can be to use a polyfill[1], and for users an extension[2].

Removal would follow the conservative approach of:

1. Offer an Enterprise Policy and a pref to disable XSLT support. (Already done.)

2. Disable in Nightly as soon as possible.

3. Disable in all channels in August 2027. This is when Chromium plans to remove their deprecation trial and enterprise policy (so that XSLT is disabled for all users).

4. After that, entirely purge the code base of XSLT and corresponding tests.

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1990759

Specification:
https://www.w3.org/TR/xslt-10/

Standards Body:
W3C

Platform Coverage:
Initially this will ship to Nightly in https://bugzilla.mozilla.org/show_bug.cgi?id=2028408, for all platforms. Deprecation for all channels through https://bugzilla.mozilla.org/show_bug.cgi?id=2066712, and removal https://bugzilla.mozilla.org/show_bug.cgi?id=1990759.

Preference:
Deprecation is done through the pref “dom.xslt.enabled” 

DevTools Bug:
None.

Extensions Bug:
None

Use Counter:
use.counter.page.xsltprocessor_constructor

Standards-Positions Discussion:
https://github.com/mozilla/standards-positions/issues/1287

Other Browsers:

• Blink: intent emailed https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4gYZeSJA/m/yNs4EsD5AQAJ 

• WebKit: cautiously supportive https://github.com/whatwg/html/issues/11523#issuecomment-3149280766 

web-platform-tests:
https://wpt.fyi/results/xml/xslt

[1] https://github.com/mfreed7/xslt_polyfill
[2] https://addons.mozilla.org/firefox/search/?q=xslt+polyfill

[Jeff Muizelaar]

It seems like this will break stuff on Nightly wherever Chrome currently has an origin trial. Can we get that list from them? Without that list, it seems like we're taking webcompat risk for limited gain.

-Jeff

--
You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CACvK8H%2BwWOyW%2BsKK1RbEgaL4r%2BnQqnW6ib9fFiRNTg%2BS3jy7cQ%40mail.gmail.com.

[Andreas Farre]

As far as I understand it XSLT has been disabled by default on Chrome
Canary, Dev, and Beta since December 2nd 2025, and their origin trial
scheduled to start yesterday. I'm not entirely sure this is what
actually happened, and I don't know if that means that they would
start running the origin trial on non-stable channels when it's been
turned off for so long. But looking at
https://developer.chrome.com/origintrials/#/view_trial/1902207892610613249
the starting version is indeed 152, which is the current release.

But just to be clear, are you suggesting that we should run our our
origin trial for Nightly only until we unship this in Aug 2028?

Andreas[2]

[1] https://developer.chrome.com/docs/web-platform/deprecating-xslt#timeline_for_chrome
correctly,
[2] Sorry Jeff for the double reply, I forgot reply all

[Jeff Muizelaar]

Are we running an origin trial?

Chrome's current disablement has presumably helped them build a list of origins currently broken with XSLT disabled. If we disable on Nightly, all of those sites will be broken and we'll have to discover them ourselves. If we can't get the list of sites that Chrome has left XSLT enabled, disabling it on Nightly has a clear webcompat cost and offers limited advantage.

So my suggestion is:

1. Copy the list of origins that Chrome has XSLT enabled and leave it enabled for those origins on Nightly

or

2. Don't disable on Nightly until Chrome's origin trial has ended (Aug 30, 2027)

-Jeff

[Emma Zühlcke]

Isn't Nightly exactly the channel for trying out new configurations? What is our stance on webcompat in Nightly? I had the impression website breakage is acceptable on Nightly, especially given that this config will reach release "soon". For folks who are testing with Nightly this is an opportunity for them to spot breakage in their own applications.

--
You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAKb2zs9-DiCXjY6%2BbH1-VoE6_p0E12UEi2mmD%3DKeD1-qw72EaQ%40mail.gmail.com.

[Simon Pieters]

To clarify the Chromium timeline, their plan is to turn it off on Stable in 158, which is in November. I assume there are very few sites that have opted in to the origin trial, since it's new and it's still enabled in Stable.

I believe we can't get origin trial participants from them, but we can run a query in httparchive to find such pages (if they're in the dataset).

Apart from the origin trial, Chromium has re-enabled XSLT (temporarily) for CAP Alert documents. We could copy this for Nightly if we're worried about annoying Nightly users who view such documents.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAPdF9uPO537cJ%3D7HFW8A4GtR9rL%2BaSP-EQVfhyTVn%3D-knZWOOw%40mail.gmail.com.

--

Simon Pieters

https://www.mozilla.com/

[Mason Freed]

Thanks for this intent! I'm obviously supportive. To confirm a few things, Chromium disabled XSLT completely on all pre-stable channels in December of last year. And we launched the origin trial in 152, which went to stable this week. There are a few registrants, but really not many yet. I don't believe I can share the list, unfortunately, but I can probably share the rough scale of the list, if that's helpful. Today there are 15 registrants total.

The current plan is to turn it off by default in 158, which goes to stable around Nov 17. That's usually when the bulk of the origin trial registrations happen. Though I'm trying to land a user-visible banner on all XSLT sites in 154 (September), which might help.

Good luck with this!

Thanks,

Mason

[Simon Pieters]

On Wed, Aug 26, 2026 at 5:57 PM 'Jeff Muizelaar' via dev-pl...@mozilla.org <dev-pl...@mozilla.org> wrote:

Are we running an origin trial?

Chrome's current disablement has presumably helped them build a list of origins currently broken with XSLT disabled. If we disable on Nightly, all of those sites will be broken and we'll have to discover them ourselves. If we can't get the list of sites that Chrome has left XSLT enabled, disabling it on Nightly has a clear webcompat cost and offers limited advantage.

I think the idea is to send a signal that we're serious about removing support, and give developers enough time to address any XSLT usage.

I'm not sure if removing support in Nightly will sufficiently reach developers, though. Maybe a user-visible message at the top of the page (for all users) is more effective? (Chrome now has such a message.)

 

So my suggestion is:

1. Copy the list of origins that Chrome has XSLT enabled and leave it enabled for those origins on Nightly

We can do this (for origins we can find in httparchive), but not until some time after November 17 (e.g. in Q1 2027).

 

or

2. Don't disable on Nightly until Chrome's origin trial has ended (Aug 30, 2027)

IMO we can be slightly more aggressive than this, but I agree we should generally avoid having an extended period of time of broken sites in Nightly while they continue to work in Chrome (due to origin trial or other).

cheers,