Agent XSLT not supported in near future. #620

Activity

1. wsobel commented on Sep 30, 2026

   

   wsobel

   on Sep 30, 2026 via email

   Member

   More actions

   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.
2. skibum1869 commented on Oct 3, 2026

   

   skibum1869

   on Oct 3, 2026

   Last edited by skibum1869

   CollaboratorAuthor

   More actions

   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
3. wsobel commented on Oct 3, 2026

   

   wsobel

   on Oct 3, 2026 via email

   Member

   More actions

   Does chromium give the error as well or only brave? I’ll be back home on Monday and begin testing myself. Thx
4. wsobel commented on Oct 3, 2026

   

   wsobel

   on Oct 3, 2026 via email

   Member

   More actions

   Chrome on my phone doesn’t have the message.
5. skibum1869 commented on Oct 4, 2026

   

   skibum1869

   on Oct 4, 2026

   Last edited by skibum1869

   CollaboratorAuthor

   More actions

   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.
6. wsobel commented on Oct 4, 2026

   

   wsobel

   on Oct 4, 2026 via email

   Member

   More actions

   Good to know. I’ll do some more research and see what I can find.
7. wsobel commented on Oct 4, 2026

   

   wsobel

   on Oct 4, 2026 via email

   Member

   More actions

   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?
8. skibum1869 commented on Oct 4, 2026

   

   skibum1869

   on Oct 4, 2026

   CollaboratorAuthor

   More actions

   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, /sample or /assets (its Accept header lists text/html first), 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 explicit Accept header and renders the same Probe, Current, Sample, Assets and Error grids as styles.xsl. XML is the default and JSON (JsonVersion 1 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 StyleType entry sets the type of the xml-stylesheet processing instruction (default text/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 Accept behind a config opt-in is the right shape, and whether BrowserView is a good name.
9. wsobel commented on Oct 4, 2026

   

   wsobel

   on Oct 4, 2026

   Member

   More actions

   Thanks a lot. I'll check it out tomorrow and integrate it into the tests and workflow.
10. skibum1869

    closed this as completedon Oct 9, 2026