Opened 8 years ago

Last modified 4 years ago

#8322 confirmed Bug

[IE] Performance problems with nested documents

Reported by: Satya Minnekanti Owned by:
Priority: Normal Milestone:
Component: Performance Version: 3.0
Keywords: IBM IE v4 Cc: Damian, James Cunningham

Description

This problem was raised by a customer using Outlook to copy and paste content into CKEditor.

When the content is pasted (or set using the source edit mode),

we are getting a stack over flow error in IE6.

IE7,IE8 Browser stopped responding when we paste the data or set the data in source and navigate to rich text view.

This issue should be fixed in ticket #8246 which was closed so we are logging this new ticket to track the issue

Attachments (4)

content.html (14.2 KB) - added by Satya Minnekanti 8 years ago.
8322_browser.html (411 bytes) - added by Garry Yao 7 years ago.
8322.patch (2.9 KB) - added by Garry Yao 7 years ago.
8322_2.patch (564 bytes) - added by Garry Yao 7 years ago.

Download all attachments as: .zip

Change History (20)

Changed 8 years ago by Satya Minnekanti

Attachment: content.html added

comment:1 Changed 8 years ago by Jakub Ś

Keywords: IE added
Status: newconfirmed
Version: 3.0

To reproduce: Switch to source, paste the code form the attachment, switch to WYSIWYG.

I have copied the html from attached file into editor and the results are as follows (very similar):

IE6 - Browser crashes. Reoproducible from CKEditor 3.0.2
IE7 - Browser throws 'Stack Overflow' and editor crashes. Reproducible from CKEditor 3.0
IE8 - Performance is very poor. Have to wait few seconds for editor reaction. Reproducible form CKE 3.0.2

IE9
Switch to source, paste the code form the attachment, switch to WYSIWYG - works fine.
Switch to source, paste the code form the attachment, switch to WYSIWYG, switch to source again - Browser couldn't handle the script. Had to close it after few minutes. Reproducible form CKE 3.0

comment:2 Changed 8 years ago by Satya Minnekanti

Should #8246 be re opened or are you going to fix this ticket in 3.6.2?

comment:3 in reply to:  2 ; Changed 8 years ago by Frederico Caldeira Knabben

Replying to satya:

Should #8246 be re opened or are you going to fix this ticket in 3.6.2?

The solution provided at #8246 already brought enhancements to this issue, reducing it's impact. I was not able to reproduce the reported problem there on most of the browsers.

You may understand that we're talking about an isolated case. It's a very unusual HTML load on a slow browser like IE6.

We can make enhancements of course. I've opened #8344 as a first step for it.

Can you please try the patch you'll find there and tell us the results it brings to you?

comment:4 in reply to:  3 Changed 8 years ago by Satya Minnekanti

Replying to fredck:

Replying to satya:

Should #8246 be re opened or are you going to fix this ticket in 3.6.2?

The solution provided at #8246 already brought enhancements to this issue, reducing it's impact. I was not able to reproduce the reported problem there on most of the browsers.

You may understand that we're talking about an isolated case. It's a very unusual HTML load on a slow browser like IE6.

We can make enhancements of course. I've opened #8344 as a first step for it.

Can you please try the patch you'll find there and tell us the results it brings to you?

Can you please try the patch you'll find there and tell us the results it brings to you? @ fredck we have tried the patch and we are seeing new issues

FF some content lost when we pasted the content and switched to Rich text ( Paragraphs of text between test line 1 & Test line 7 are missing.)

IE9 browser crashes when we paste the text go to rich text back to source and then back to Rich text

IE(6,7,8), FF ,Opera 2 new empty paragraphs( ) added at beginning of doc every time we navigate between souce and rich text or we destroy and create Editor instances

comment:5 Changed 8 years ago by Frederico Caldeira Knabben

@satya, I would appreciate your comments on #8344 directly, with eventually the steps to reproduce all of your findings.

comment:6 Changed 7 years ago by Jakub Ś

#8479 was marked as duplicate.

comment:7 Changed 7 years ago by Garry Yao

Keywords: VendorFix added

We're not able to deal with the paste performance issue here, since the browser hangs up itself in a raw contenteditable with the sample tc, this should be instead a IE feedback ticket, thus any benefit brought by #8344 will be significant in helping this case.

comment:8 Changed 7 years ago by Damian

@garry, could you please provide a sample that demonstrates that this is an IE problem? I have been unable to reproduce the performance issues when setting up an IFrame with contenteditable on the body, with the test case content. IE works reasonably well with this content.

Changed 7 years ago by Garry Yao

Attachment: 8322_browser.html added

comment:9 Changed 7 years ago by Garry Yao

Component: GeneralPerformance
Keywords: VendorFix removed

Sorry, in a double check I concluded IE is wrongly blamed above, I've attached a tc to show it works plain fine on its own as pointed by damo.

Changed 7 years ago by Garry Yao

Attachment: 8322.patch added

comment:10 Changed 7 years ago by Garry Yao

8322.patch is to prove that this is still a selection ranges performance issue like #8246, IE9 works fine after the patch when pasting.

Changed 7 years ago by Garry Yao

Attachment: 8322_2.patch added

comment:11 Changed 7 years ago by Garry Yao

Some further investigation shows like this may not even being a performance issue, but perhaps a dead loop caused the (a wrong?) range position, this can be verified by 8322_2.patch which returns a synthetic offset from the range and it amazingly stop the hang up, though I didn't manage to figure out what exactly goes wrong.

comment:12 Changed 7 years ago by Garry Yao

On IE8/IE9 instead the profiler shows bottleneck exists in moveToElementText method which takes roughly 200ms for each run, but it's evident that we're inevitable from using it.

comment:13 Changed 7 years ago by Frederico Caldeira Knabben

Keywords: v4 added

comment:14 Changed 4 years ago by Piotrek Koszuliński

It takes about 3-4s on my IE11 (on VirtualBox) to process this document. It takes ~100ms on Chrome.

comment:15 Changed 4 years ago by Piotrek Koszuliński

I've made one more test – I loaded that content as a normal (static) website in IE11. It also took it ~3s to load. So it seems that CKEditor is not adding any significant overhead here (at least in this browser). But in fact the content is the problem (it's absolutely broken), not the browser.

comment:16 Changed 4 years ago by Anna Tomanek

Summary: IE: Performance problems with nested documents[IE] Performance problems with nested documents
Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy