Repository navigation
Agent XSLT not supported in near future. #620
Description
Activity
- What browser is giving this warning? I’m not sure if there is another solution that can allow for viewing of the content as anything other than xml.
Brave which runs the chromium backend. Safari does not list the error.
Chrome is officially removing native client-side XSLT support, with the feature scheduled to be disabled by default on Stable releases on November 17, 2026 (targeting Chrome 158)
https://developer.chrome.com/docs/web-platform/deprecating-xslt- Does chromium give the error as well or only brave? I’ll be back home on Monday and begin testing myself. Thx
- Chrome on my phone doesn’t have the message.
Does chromium give the error as well or only brave? I’ll be back home on Monday and begin testing myself. Thx
yes it does, or at least Chrome on the Mac does.
- Good to know. I’ll do some more research and see what I can find.
- Background from Claude: Reason: Chrome is removing XSLT primarily for security. Chrome's position is that keeping XSLT 1.0 in browsers poses a serious and avoidable risk, because libxslt, the library Chromium uses, is a complex and aging C/C++ codebase, and libxslt went unmaintained for about six months of 2025. Context: after Project Zero and Positive Technologies reported long-standing libxslt bugs, the libxml2 maintainer, frustrated by the lack of contributions from big downstream users like browsers, changed the security policy and stepped down from libxslt. Low usage (roughly 0.01–0.1% of page loads) and the fact that browsers are frozen at XSLT 1.0 from 1999 while the language moved on to 2.0 and 3.0 sealed it. Gecko and WebKit also support the removal, and XML itself stays in the browser. Timeline: XSLT stops working on Stable in Chrome 158 (Nov 17, 2026) except for Origin Trial and Enterprise Policy participants, and those escape hatches end with Chrome 176 (Aug 17, 2027).…_____________ For the MTConnect agent's browser view of probe/current/sample (the xml-stylesheet styles), this will bite. The cleanest long-term options are a small HTML/JS client served from the agent's static files that pulls XML or JSON, or an HTML representation the agent produces through content negotiation. The polyfill is the quick bridge in the meantime._____________ We have a little time. I could either do server side xslt if the accepts have html first or we could do a JS rendering that would do effectively the same thing but without xslt. Effectively wrapping out xml in xhtml and then using some js to transfer transform it into the html rendering. Any preferences?
I put together a proposal for this as a draft PR: #621
In short:
- An opt-in
BrowserView { Location = /styles/viewer.html }config entry. When a browser requests/probe,/current,/sampleor/assets(itsAcceptheader liststext/htmlfirst), the Agent returns a small static page. Clients that send*/*, an XML type or a JSON type, and any request with?format=, get exactly what they get today. - The page is JavaScript served from the existing
styles/folder. It re-requests the same URL with an explicitAcceptheader and renders the same Probe, Current, Sample, Assets and Error grids asstyles.xsl. XML is the default and JSON (JsonVersion1 and 2) can be selected, so the Agent stays a read-only source and the viewer only sends GET requests. No new native dependency is needed. - An optional
StyleTypeentry sets thetypeof thexml-stylesheetprocessing instruction (defaulttext/xsl). The XSL files are unchanged and still work for browsers that support XSLT.
I built it from the Ubuntu Dockerfile and checked the views in a browser against the demo devices, in both XML and JSON. The PR description lists what has not been done: the repository's unit tests were not run and I added no C++ tests, JSON v1 was only checked against the printer source, and there are a few hardening follow-ups.
I'd like feedback on the approach before polishing it, in particular whether serving a page based on
Acceptbehind a config opt-in is the right shape, and whetherBrowserViewis a good name.- An opt-in
Thanks a lot. I'll check it out tomorrow and integrate it into the tests and workflow.
We've been getting notifications that the XSLT display will be removed in the near future, so I wanted to make sure it is noted for replacement.
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. You might be able to install a browser extension that allows you to continue viewing it. Otherwise, you should contact the maintainer of the site for further information.