Opened 10 years ago

Last modified 8 years ago

#12062 confirmed Bug

Performance issues typing at the end of a large document in IE and Chrome

Reported by: Rick Schnorenberg Owned by:
Priority: Normal Milestone:
Component: General Version: 4.0
Keywords: Blink IE VendorFix Cc:


Steps to reproduce

  1. Open the nightly demo page:
  2. Load a large document into the editor (I have attached a 30KB sample document)
  3. Type at the beginning and end of the document and compare the performance. In the affected browsers characters appear very slowly and the caret is often displayed 1 to 2 characters behind the actual insertion point.

Browser and OS

This issue occurs on Chrome in any Operating System, Internet Explorer 11 on any Operating System, and Internet Explorer 10 on Windows 8.

Firefox performs well in any Operating System. Internet Explorer 9 and 10 on Windows 7 perform well.

Attachments (1)

ipsum no tags.html (33.3 KB) - added by Rick Schnorenberg 10 years ago.

Download all attachments as: .zip

Change History (8)

Changed 10 years ago by Rick Schnorenberg

Attachment: ipsum no tags.html added

comment:1 Changed 10 years ago by Matti Järvinen

Cannot reproduce on Chrome.

IE11 is quite slow when I paste lipsum in source view and lipsum text is marked for spelling errors. When I return to WYSIWYG typing is slow. When I toggle back to source spelling errors are gone.

If I copy previous slow lipsum from previous step (ctrl+a , ctrl +c) in WYSIWYG and reload the page and select everything and paste content in WYSIWYG CKEditor stays fast and when I toggle to source view text is not marked for spelling errors.

Could that initial spellchecking make whole editor slow? Maybe adding spellcheck="false" to the input could help?

comment:2 Changed 10 years ago by Jakub Ś

Keywords: Blink IE added
Status: newconfirmed
Version: 4.0

I was able to reproduce this problem from CKEditor 4.0 on Blink and IE browsers.

In my case, both Opera and Chrome have shown this issue on Windows 7.
IE11 has shown this issue on windows 7.
I could not reproduce this problem on IE8-10, Webkit or Firefox.

The only inconsistency i see with original TC is IE10 which hasn't performed well for @rschnorenberg.

comment:3 Changed 10 years ago by Piotrek Koszuliński

Keywords: VendorFix added

I reproduced the same issues on pure <div contenteditable=true> with this long paragraph on Chrome. So it's some internal browser problem I am afraid. I also recorded some timelines and there's no evidence of any CKE's code causing that. At the first sight it looked that it might be caused by undo manager, but disabling it does not help - CPU or timeline profiles are clean but Chrome renders with ~3-5FPS.

I don't have more time to check it on other browser nor to report bugs to browser vendors. If you have, then that would be great.

comment:4 Changed 10 years ago by Rick Schnorenberg

One of our developers has opened a ticket with Microsoft about this issue: 925659

comment:5 Changed 10 years ago by Piotrek Koszuliński


comment:6 Changed 8 years ago by PAQUET


Do you have any news about this issue ? With a large html document (~200ko for instance) firefox 41 performs well. Chrome 46 (I think since 44 maybe) is nearly unusable in source mode. As the comments said it seems to be a browser issue (don't see any javascript method that consumes resources) Would it be possible to open a ticket on chromium project as well ?


comment:7 Changed 8 years ago by PAQUET

Edit :

It seems that disabling spellcheck as suggested by matti fixed the problem

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy