When pasting images, editing of text becomes very slow

[mkrecek234]

Description

I am mostly using Trumbowyg on macOS Safari an have enabled the respective plugins to allow pasting images into the editor which are stored as base64 HTMLs.

However, when pasting an image, the text editing becomes very laggy and slow.

How to reproduce?

You can try it yourself on the trumbowyg demos webpage where after an image was pasted, text editing becomes very slow.

Any chance to speed this up, so it is still realistically usable for HTMLs with pasted images?

[lithxe]

Commenting to note that I have experienced this too, and limiting the size of the images down to a quite small 500px maximum on either side has helped a lot, though it will still be an issue if your users fill the text box with a bunch of images. This can be done in the trumbowyg.base64.js file down around line 143 within the if (isValidImage(e.target.result)) { function, something like:

var image = new Image(); image.src = e.target.result;

image.onload = function() { if(this.width > 500) { alert('Image is too large. Sorry! Files pasted in the editor have a limit of 500px on either side to avoid high load times.'); return false; } else if(this.height > 500) { alert('Image is too large. Sorry! Files pasted in the editor have a limit of 500px on either side to avoid high load times.'); return false; } else { trumbowyg.execCmd('insertImage', fReader.result, false, true); $(['img[src="', fReader.result, '"]:not([alt])'].join(''), trumbowyg.$box).attr('alt', values.alt); trumbowyg.closeModal(); } };

That being said, the issue was not apparent until we launched with the editor and it's definitely a pain point!

[Alex-D]

Is it only on Safari?

[mkrecek234]

Is it only on Safari?

From my perception this is not only a Safari issue but also seen in Chrome: it seems solely to be an issue with slightly larger pictures. Question is why it slows it so much down, as while typing the image is simply "moved" and should ideally not consume so much CPU power.

[Alex-D]

I think it's due to the synchronization between contenteditable and textarea, which makes a lot of data to transfer on each keystroke and update in the DOM.