Poor performance making many synchronous calls to xss filter service

I've ran into this issue as well. I've created a patch that will create a option in the general settings form to make the ajax call asynchronously instead of the now fixed synchronous call.

Changing the call to asynchronous basically means that the rendering of the page won't wait anymore on the Ajax calls. Especially on pages with large amounts of WYSIWYG fields this means a large performance gain.

+1 on the patch in #2
Works like a charm.

This patch is nice, but why make this configurable? When would you want these requests to be synchronous, blocking ANY user interaction until all the wysiwyg fields finish loading?

They should also probably be batched: one round-trip, one Drupal bootstrap time.

Furthermore, why does this processing even happen server-side but after the page is loaded?
Should it not happen during the initial request, if not, should it not happen client side?

Here's a much simpler async patch.

BTW, I'm not just being contrary about the async point. Chrome before this patch gives me a nice console log message:

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.

The docs from WHATWG elaborate as follows:

Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user's experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when entry settings object's global object is a Window object. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs.

Too bad more browsers aren't moving forward with the InvalidAccessError exception, otherwise this code wouldn't have ended up in this module in the first place.

Updated patches.

The sequentially numbered are straight from git format-patch, they're my branch I've been working on this in.

I've got two Drupal-formatted patches, one for just making this async, the other goes further to allow batch processing.

On my problematic form, I go from 110 requests to 38 requests with batch coalescing.

@lotyrin, Your patch ckeditor-async-xss-2578271.patch resulted in blank white page for admin/config/content/ckeditor/addg page, as reported by Drulenium visual regression test. Complete report at http://drulenium.org/projects/drupal-module-ckeditor-7x-1x-desktop/conso...

$ echo "Applying PATCH $PATCH_FILE_URL"
Applying PATCH https://www.drupal.org/files/issues/ckeditor-async-xss-2578271.patch
$ wget $PATCH_FILE_URL
converted 'https://www.drupal.org/files/issues/ckeditor-async-xss-2578271.patch' (ANSI_X3.4-1968) -> 'https://www.drupal.org/files/issues/ckeditor-async-xss-2578271.patch' (UTF-8)
--2016-09-10 05:41:51--  https://www.drupal.org/files/issues/ckeditor-async-xss-2578271.patch
Resolving www.drupal.org (www.drupal.org)... 151.101.32.68
Connecting to www.drupal.org (www.drupal.org)|151.101.32.68|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 488 [text/plain]
Saving to: 'ckeditor-async-xss-2578271.patch'

     0K                                                       100% 5.02M=0s

2016-09-10 05:41:52 (5.02 MB/s) - 'ckeditor-async-xss-2578271.patch' saved [488/488]

$ PATCH_FILE_NAME=$(basename "$PATCH_FILE_URL")
$ patch -p1 < $PATCH_FILE_NAME
patching file includes/ckeditor.utils.js

Console Log: https://gitlab.com/Drulenium-bot/ckeditor/builds/3927283#down-build-trace

@loytrin
Thanks for your work, this has been driving me mad for ages. I have even been creating multiple admin pages just to mitigate the long load time of CK Editor.

I applied the ckeditor-batch-xss-2578271.patch and my page load for an admin page with lots of text format fields has gone from making 22 separate xss requests taking almost 30 seconds to load the page to 1 xss request and the page loading in under 6 seconds! The 1 request getting all the info takes the same amount of time as an individual request did before.

I will do some further testing but I have not found anything no longer working.

is this an issue in Drupal8?

I experience the same problem using paragraphs. My workaround is in ckeditor.utils.js:166 and I replaced this...

$.ajax({
        type: 'POST',
        url: Drupal.settings.ckeditor.xss_url,
        async: false,
        data: {
          text: $('#' + textarea_id).val(),
          input_format: ckeditor_obj.textarea_default_format[textarea_id],
          token: Drupal.settings.ckeditor.ajaxToken
        },
        success: function(text){
          $("#" + textarea_id).val(text);
          Drupal.ckeditorInit(textarea_id);
        }
      })

...with this...

Drupal.ckeditorInit(textarea_id);

Struggling with this... Any updates coming?

v1.19

Patch: ckeditor-batch-xss-2578271.patch

Hunk #1 FAILED at 141.
Hunk #2 succeeded at 174 (offset 11 lines).
1 out of 2 hunks FAILED -- saving rejects to file includes/ckeditor.utils.js.rej

On a side note, I updated to 1.19 and tried to apply this patch before actually testing things... I re-downloaded a clean 1.19 and tested without the patch. The editor loads pretty quickly so I guess we'll see what happens.

For the time being, under D7, this solves my issue:

// Prevent unwanted caching.
if (false && run_filter && ($("#" + textarea_id).val().length > 0) && typeof(ckeditor_obj.input_formats[ckeditor_obj.elements[textarea_id]]) != 'undefined' && ((ckeditor_obj.input_formats[ckeditor_obj.elements[textarea_id]]['ss'] == 1 && typeof(Drupal.settings.ckeditor.autostart) != 'undefined' && typeof(Drupal.settings.ckeditor.autostart[textarea_id]) != 'undefined') || ckeditor_obj.input_formats[ckeditor_obj.elements[textarea_id]]['ss'] == 2)) {
// if (run_filter && ($("#" + textarea_id).val().length > 0) && typeof(ckeditor_obj.input_formats[ckeditor_obj.elements[textarea_id]]) != 'undefined' && ((ckeditor_obj.input_formats[ckeditor_obj.elements[textarea_id]]['ss'] == 1 && typeof(Drupal.settings.ckeditor.autostart) != 'undefined' && typeof(Drupal.settings.ckeditor.autostart[textarea_id]) != 'undefined') || ckeditor_obj.input_formats[ckeditor_obj.elements[textarea_id]]['ss'] == 2)) {
$.ajax({
type: 'POST',
url: Drupal.settings.ckeditor.xss_url,

This patch will be a huge relief to some particularly complex sites with a lot of fields. Though currently the batch processing patch doesn't apply cleanly to the current 2.21 release. Also, if I just apply the async patch, I begin getting an error message like this, for what I assume is each CKEditor instance.

Uncaught The editor instance "edit-body-und-0-value" is already attached to the provided element. ckeditor.js 341 

Though this doesn't seem to affect my ability to interact with the form. I'm still apprehensive to commit a a patch that generates an error like this.