wysiwyg-editor
wysiwyg-editor copied to clipboard
Highlighting a large amount of text is unresponsive (performance regression)
When a large amount of text (potentially over 150KB) is highligted, the editor becomes unresponsive. (This is before any modification happens to that text -- just the act of highlighting it.)
The easiest way to reproduce this is to:
- Go to https://froala.com/wysiwyg-editor/ and view the page source. (As of right now, it's about 170KB of text.)
- Copy that out and paste it into a plain text editor. This is because in Chrome (at least) when pasted directly from view source, the result is a table which is even more complex. Pasting in to a plain text editor gives us simple text.
- Copy the plain version and paste that into the editor - this will take a little bit of time but not too long.
- Now use ctrl+A to highlight everything. This will hang for a significant amount of time. You can see this by trying to hover over the toolbar buttons -- they won't react.
Eventually, it will recover (though this can be up in the air). However, even attempting to unhighlight takes a huge amount of time. Alternatively, deleting the content is also very slow.
While this may feel like a contrived example, it's possible a user may not realize the contents of their clipboard and paste a huge amount of content accidentally. Because of the speed issues here, it's hard to recover from an accidental large paste. As a comparison, both TinyMCE and CKEditor remain performant throughout and the errant content is easily removed.
Editor version.
3.2.1
OS.
Tested on Windows
Browser.
Chrome 85
Oh as a follow up, the performance of this in Froala 2.x is significantly better, so this is really a performance regression.
Looks the same as https://github.com/froala/wysiwyg-editor/issues/3982
Experienced the same issue in 3.2.3. The problem is that its not just copy/paste problem. User can build up a bigger content during some time (e.g. pasting smaller content multiple times) and he will end up with content that is unable to be all selected. Looks like the issue is not related to number of chars or size in general, but more the html is structured (e..g many p tags, etc..) the more the problem occurs.
is there any update on the issue? is it planned to be fixed?
I think this is fixed in 4.0.9 as well as the related #3982
Hi, yes it is working now, editor is still responsive on select. Thank you!