Context UDA-12 (fixed in 1.2.7) changed how the sections tree of UnifiedDocumentSectionDisplayer loads the tree WebJAR: it registers a RequireJS alias xtree through require.config and points it to require-config.min.js of
xwiki-platform-tree-webjar.
Problem require-config.min.js is a Velocity template that only publishes RequireJS paths as a side effect of require.config(). It defines {}no AMD module{} and does not set $.fn.xtree. RequireJS therefore treats it as a "plain
script": the xtree module resolves as soon as that file is loaded, with an undefined export. The callback of:
require(['jquery', 'xtree', 'xwiki-selectize'], function($) { ... })
can then run while tree.min.js (the real module defining $.fn.xtree) is still being downloaded, which randomly breaks the sections tree with:
This is a pure timing issue: setting a breakpoint (slowing down execution) makes the error disappear. It also only seemed to work on some XWiki versions because the platform's own tree widget (e.g. the breadcrumb) happened to load
tree.min.js concurrently, before the application code. Steps to reproduce
- Install Unified Documents Application 1.2.7 on a recent XWiki (17.10+)
- Open the sections tree of a unified document (view or edit)
- The tree randomly fails to render, the browser console reports Uncaught TypeError: b(...).xtree is not a function
Proposed fix Require the standard xwiki-tree module published globally by the Flamingo skin since XWiki 15.10:
require(['jquery', 'xwiki-tree', 'xwiki-selectize'], function($) { ... });
Since it is the real AMD module of the WebJAR (tree.min.js), AMD guarantees that $.fn.xtree is defined before the callback runs — the race is gone. This required bumping the application's parent-platform to 15.10. |
