Quick comment editor loads very slowly and falls back

This supersedes CONF-27023, whereby the fallback mechanism of editor loading is broken.

Although we are fixing the worst part of that issue in 5.5.1, there will still be Confluence instances where the editor loads very slowly.

This can happen for a variety of reasons but the most common one is when the editor resource batching falls apart due to a plugin. This is technical and complex.

The editor quick-loading works by fetching the additional javascript and css resources required to show the editor, after the page has loaded. These are fetched as a couple of batches (eg batch.js and batch.css), so there aren't very many individual js and css files downloaded to show the editor. The batches are cacheable, improving things further.

However, if some of the resources in the editor batch were already required to view the page, then the batch provider takes drastic action. It doesn't want to give out a batch that contains a resource that's already been loaded, because then it would be loaded twice, which could break things. So, it unbatches the batch and provides the resources individually.

Therefore, the dynamic editor loading has to download dozens of resources instead of 4-6, which takes much longer.

This is usually because a plugin, either Atlassian or 3rd party, is misbehaving in a very subtle way.

How to determine why the comment editor loading is slow:

These steps are currently slightly unverified but should work - if you run into any issues let us know in the comments below.

1. Navigate to a page where the comment editor is known to load slowly
2. Open the javascript console of your browser.
3. Execute

   AJS.$(AJS.$('meta[name="ajs-editor.loader.resources"]').attr('content')).filter('script').size()
   AJS.$(AJS.$('meta[name="ajs-editor.loader.resources"]').attr('content')).filter('link').size()

4. If these do not return small numbers, less than about 6, then your resources are unbatched (this is bad).
5. Turn up logging on the server for com.atlassian.plugin.webresource.assembler.DefaultWebResourceAssembler to DEBUG
6. Visit a page and do a hard refresh
7. Find the line in the server logs that looks like this

   "The module '<some module>' has already been included in the Assembler. Inclusion contexts = <some contexts>, required contexts = <some more contexts>"

8. Determine which plugin is requiring the <some module>. If you're lucky it's obvious. If you're unlucky, you might need to turn off a lot of plugins to stop it happening. If this happens on specific pages, try removing the macros used on those pages to see if the logging stops.
   If you don't see this logging, then your older version of Confluence probably doesn't have that logging. Talk to support to confirm that, they might just need to find a different class to increase logging for, and upgrade to a newer version.
9. Report the problem to the plugin developer. If this is Atlassian, let us know in a comment below. They may need to use separate resources for the editor and view page. Or they may just need to use resource contexts instead of using resources directly.