Quick Comment Loader Freezes Safari

Updated Summary:

Plugins that use conditions for Atlassian editor resources may cause the browser to freeze in certain environments. This happens with Gliffy < 6.0 due to the condition that controls which Gliffy Editor is launched (flash vs html5). If you use Gliffy, updating to 6.x+ should resolve your issue. However, Atlassian should still fix this issue, as this prevents plugins from being able to use conditions for Editor resources.

As Paul noted, this may also happen with other plugins that also use editor conditions like the 'create-content' plugin in Confluence 5.0

https://developer.atlassian.com/display/DOCS/Web+Item+Plugin+Module#WebItemPluginModule-ConditionandConditionsElements

Original:
I believe this was filed as https://jira.atlassian.com/browse/CONF-25054 and was supposed to be resolved in CONFDEV-8038

On certain customer instances when loading a Confluence page with Gliffy enabled, the browser will freeze for a few seconds so you cannot scroll or click on elements. After profiling, it appears that the culprit is atlassians quick comment loader. It basically loads more scripts for the comment editor by creating dynamic script tags and appending it to the document head. Theoretically this should be non-blocking (using dynamic script tags to perform gets should not block rendering) but it appears that in webkit there may be an obscure bug, or it may be delaying the onload event. This behavior is not present in FF and IE even though the batch js request is just as slow.

If you inspect the network tab on the affected sites, the page will hang when it attempts to load particular batch.js files that the comment loader requests. Each one takes around 2+ seconds to receive which is why the page is paused for so long. And indeed if you open up the js console, you'll see: "EditorLoader: 2 scripts to be loaded." before the page hangs for a few seconds as the js is loaded.

One of our customers reports that they see this issue when they have enabled the Gliffy plugin.

Why is Gliffy interacting with this?

If you inspect the code present in AJS.Confluence.EditorLoader.load the loader has two code paths: one is if there is a single file and the other is when there are multiple. The loader uses the a straightforward jQuery.ajax call for a single file, and the dynamic script tag approach when there are multiple.

if (resources.jsUrls.length > 1) { 
var $head = AJS.$("head"); 
AJS.$.each(resources.jsUrls, function(index, jsUrl) { 
var $script = AJS.$("<script></script>"); 
$script.attr("src", jsUrl); 
$head.append($script); 
setTimeout(loadCallback); // calling loadCallback in the same 'event' seems to cause weird problems in Firefox on Linux. 
}); 
} else { 
// To avoid CONFDEV-8038 prefer this mechanism for the normal (single batched resource) case. 
AJS.$.each(resources.jsUrls, function(index, jsUrl) { 
ajaxSettings.url = jsUrl; 
AJS.$.ajax(ajaxSettings); 
}); 
}

It may be that our plugin is bumping the number of files to be loaded, so it uses the dynamic tag approach. If it isn't it, it may be that this issue is more noticeable when the batch files are larger.