ONLYOFFICE Workspace Community does not display files in Chrome 144+ due to XSLT removal

For bug reports, provide the steps to reproduce and if possible a minimal demo of the problem:

  1. Open OnlyOffice Workspace in Chrome/Chromium Canary.
  2. Use any Workspace portal with existing folders/files.
  3. Open the File Manager section.
  4. In Chrome 144+ (e.g. Chrome Canary 144.0.7559.4), the file list does not load — the folder appears empty.
  5. Open Developer Tools → Console.
  6. The following error appears:
files-SAynPeOtFIx70gcybZV3uA2.js?ver=12.7.1.1942:4 
Uncaught Can't translate xml : NotSupportedError: 
Failed to construct 'XSLTProcessor': XSLT is disabled

The problem does not occur in Chrome 143.0.7499.41 (works correctly there).


Community Server/Control Panel version:

onlyoffice/documentserver:9.2.0.1
onlyoffice/communityserver:12.7.1.1942
onlyoffice/controlpanel:3.5.4.54
onlyoffice/elasticsearch:7.16.3
mysql:8.0.29

Type of installation of Workspace:
Docker


Browser version:

  • Chrome 144.0.7559.4 (Canary) — :x: not working
  • Chrome 143.0.7499.41:heavy_check_mark: working

Additional information:

This issue occurs because Chrome/Chromium has started removing XSLT support (XSLTProcessor API) in versions 144+.
OnlyOffice Workspace relies on XSLT transformations to render the file manager UI. When XSLT support is removed or disabled in the browser engine, the interface cannot display files or folders.

I tested the Chrome extension “XSLT Polyfill”, which removes the console error message but does not restore actual functionality, because the polyfill cannot handle the complex XSLT transformations used by Workspace.

I also opened an official Chromium issue describing this breaking change on the browser side:
https://issues.chromium.org/issues/465491619

Once Chrome 144 reaches the stable channel, the Workspace file manager will stop working for all users of Chromium-based browsers (Chrome, Edge, Opera, etc.), which makes this issue critical.

Update from the Chromium team:

I have received an official response from a Chromium engineer regarding the issue.
Here are the important details:

  1. The problem in Chrome 144+ was caused by an experimental early removal of XSLT, which unintentionally ignored the chrome://flags/#xslt setting.
  2. Chromium has confirmed this is a bug in their trial, not in OnlyOffice.
  3. They will scale back the experiment and restore XSLT functionality in upcoming Canary builds so that OnlyOffice Workspace will work again temporarily.
  4. However, they also confirmed that:
  • XSLT WILL be fully removed in Chrome according to the official deprecation timeline,
  • An Enterprise Policy and a Deprecation Trial will be introduced, but they are not yet available,
  • Vendors (such as OnlyOffice) will need time to migrate away from XSLT.

I have also shared the OnlyOffice issue with the Chromium team, as requested.
Here is the Chromium bug where this was discussed:
https://issues.chromium.org/issues/465491619

Since Chrome 144 will eventually reach Stable, this will affect all Chromium-based browsers (Chrome, Edge, Opera, etc.). It would be helpful if the OnlyOffice development team could confirm whether the transition away from XSLT-based UI rendering is planned.

2 Likes

Just checking in here with a few data points:

  • See this post for more information, including the timeline: Removing XSLT for a more secure browser  |  Web Platform  |  Chrome for Developers
  • The recent breakage of XSLT is the result of an experiment on pre-stable channels only, e.g. Chrome Beta, Dev, and Canary. So it should not affect most users. (It is intended to find exactly the sort of bugs like https://crbug.com/465491619.)
  • The pre-stable experiment has been temporarily halted due to the above bug, but once I get that fixed (next week or so), I plan to restart the experiment. So pre-stable Chrome users might again experience breakage on OnlyOffice.
  • If you need advice or assistance in migrating off of XSLT, feel free to check in with me.

Thanks,
Mason

1 Like