SharePoint SE 23H2 bug on themed sites - long page load times & faulty theme previews - fix included 👇

C.J. Damsleth — Fri, 13 Oct 2023 12:28:26 +0000

tl;dr: There's a bad bug in the SharePoint Subscription Edition 23H2 Feature Update, and I wrote a Powershell script to patch your 16-hive until Microsoft issues a patch of their own. Script at the bottom.

A colleague of mine encountered issues in a client's onprem SharePoint Subscription Edition farm last week, immediately following the deployment of the 23H2 update.

The Bug(s)

While attempting to preview themes, an error message appears: There was an error when trying to preview the theme.

On its own not a big deal. Applying the theme works, seems to be just the previewing that's borked.

However, the real bug happens when you apply a theme, then try navigating between themed sites. Significant delays — up to 10 seconds, and no error message in the console or UI.

Notably, these delays do not occur when navigating between pages within the same site, as theme loading is site-specific. See e.g. localStorage.odThemecachetoken, which has a site specific value a là "/sites/siteurl/_catalogs/theme/Themed/SOME_HEX_ID".

clearing one or more of the localStorage.od* properties, or just localStorage.clear() triggers the bug in the same way as cross-site navigation does.

Observe the lag in rendering the theme UI, and look at the Performance call tree(!)

Classic recursion-iceberg

It's handleThemeChange all the way down

The nitty gritty

On closer examination, the delays look to be due to a recursive js-bug, triggering Maximum call stack size exceeded errors. This issue is traced back to a bug in the sp-pages-assembly.js script, with uniqueId pxHxh (most SharePoint js-files get loaded with a uniqueId query string suffix which is unique to the patch version).

The bug affects the handling of new effects and spacing theme properties in the createTheme and spLoadTheme functions.

If you're curious to see the recursion in action, put a breakpoint in sp-pages-assembly.js, on the line containing the following: Object(N.isEqual)(Object(M.createTheme)(e),e)||Object(k.spLoadTheme)(e) and step from there.

Anyway, after some painful debugging of mini- and uglified SharePoint scripts, I found out that adding default values to the effects and spacing properties in the default theming object (which already contains palette, fonts, semanticColors, isInverted and disableGlobalClassNames properties), the recursion-bug does doesn't trigger.

To make it easier to implement, I wrote a small PowerShell script. It does a quick-and-dirty find/replace operation in all sp-pages-assembly.js files in the 16-hive. By running this script on all web front ends, the theme preview function should operate correctly, and page load times should be back to normal

A Word of Caution

Modding JS files in the 16-hive is not advisable under normal circumstances. It's a hack. It's bad. It will make your average SharePoint admin wince. We did this shit in the late 00's, together with custom master pages and GAC'ed .dlls, and it usually ended badly.

The modifications introduced by the PowerShell script are temporary and will be overwritten by Microsoft’s next CU. Hopefully, Microsoft will release a fix for this bug in the upcoming update, rendering this makeshift solution unnecessary.

Full script below in case you don't like github gists for some reason 👇

Patch