Several problems with navigation tree - not displaying subpages in documentTree macro

I have several problems with navigation panel (documentTree macro):

  1. Sometimes subpages for a given page are not loaded/displayed at all. Page D-Hours has one subpage caled .NET created by me. Users have right to see/access this page.


  1. If user has restricted access to some of the subpages a message XX more... is displayed instead of the allowed pages. In other words user has access to only 2 out of the 92 subpages of Projekty. After clicking the Projekty in document tree he/she sees only these subpages that are within the default range (e.g. only CBK). He/she has to click 91 more… in order to see next available pages that are out of this range (see gif).


  1. Sometimes the navigation tree is not displayed at all. At the moment problem was detected only in Chrome (I use 68.0.3440.106 on Windows without Adblock). Usually it’s enough to refresh the page to see the document tree again.


In thread #3206 - Navigation tree view performance problem we already discussed problem with navigation tree and I decided to load it with showDocumentTitle="false" argument. It’s not the most convenient but allows to load pages in document tree in reasonable time.

I’d love to solve at least 1st and 2nd of the above problems. Do you have any ideas what might be the reasons?

That’s because the HTTP request to get the tree nodes goes through the XWiki Rendering which by default applies the icon transformation and thus breaks the generated JSON. Here’s what the tree gets:

    "icon":"fa fa-file-o",

Simply because xwiki:D-Hours is transformed into “xwiki :smiley: -Hours” which is then rendered as plain text into xwiki-Hours.

The solution until we fix XWIKI-13167 is to disable the icon transformation.

Unfortunately that’s true also for the live table and for the search page and it’s not easy to fix. The root problem is that we can’t fetch the results and check access rights in a single query. So we do it in two steps: fetch the results and then filter out those for which you don’t have the proper access rights. This can be done in 2 ways:

  1. fetch pages of N results and collect the results that match access rights until we either collect N results (a page) or we have no more results. From the performance point of view this is crazy. You could for instance have 1k child pages and check rights for each of them just to find out that the current user can’t access any of them. It would slow down the tree / live table / search even more.
  2. fetch pages of N results and display only the results that match access rights. It’s definitely not nice for the users but it’s fast.

So I don’t have a quick fix for this issue.

I’ve heard others complaining about this (ping @Enygma ) but I don’t have this problem. You should check the JavaScript console from the browser’s developer tools when it happens to see if there is a JavaScript exception.

Thanks all for your replies :+1:.

The trick with disabling emoticons worked as expected :white_check_mark:.

I also carried out a simple experiment with different settings of document tree macro, but it’s still unbearably slow with showDocumentTitle="true".

Perhaps anyone has some hack to cache this or generate static version of the document tree?

I committed a fix for 10.8 that doesn’t require to disable the Icon Transformation. See .

1 Like

@mflorea: Yes, I used to get that much more often on the older versions of Firefox. Back then (~1 year ago), Firefox was much slower and, under heavy load, it might expose some race conditions or hit some timeouts that don’t occur often under normal conditions. What I do remember is that almost in all the cases where some JavaScript failed to load (like in the case of the Navigation panel’s tree code), I would get a RequireJS error in the JavaScript console complaining that it failed to load tree.js, or something like that.

In the recent versions, Firefox has progressed a lot (in terms of stability and speed) and I do not experience those JavaScript related problems anymore.