IE7 maximize long delay

[bbone]

In IE7 (IE 7.0.6002.18005 / OS: Windows Vista SP2) it takes about 4-5 seconds to maximize/minimize the editor (using Maximize button).

[Jakub Ś]

I have done some research on this ticket. Here are the results:

1. I affects only IE6 and IE7
2. The time of maximize increases as CKEditor is burried deeper in DOM structure (In IE6 and IE7 operations carried out on DOM are very slow)
3. Below are the results of tests carried out in IE7 for CKEditor "buried" in 20 divs (See 8587.html)

CKE ver. | time max/min (ms)
3.0 | 861/831
3.3 | 1091/1051
3.4 | 1111/1062
3.4.1 | 1181/1112
3.4.2 | 1172/1142
3.4.3 | 1261/1111
3.5 | 1412/1262
3.6.2 | 1442/1252

• It looks like time for maximize/minimize increases.
• The test carried out in CKEditor buried in 20 divs gave the result of about 1,5 sec. @bbone would it be possible to provide a TC for which maximize takes about 5 sec? How deep your CKEditor is buried in DOM? Perhaps some special DOM structure is causing this?

To workaround the problem: Don't go to deep with CKEditor. At least not in IE6 and IE7 as all other browsers work fine.

[bbone]

I think that my testing environment is too slow.
CKEditor is buried 10 levels deep (8 divs, 1 form, 1 span).
The same environment need ~3,7 sec. for 8587.html

[Jakub Ś]

There is one more thing I might suggest here: ​http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.editor.html#resize - seems to be much faster

You could try using this method in your custom plugin instead of maximize plugin (You could even use the same icon for that).

As for size coordinates these could be either

1. fixed (won't be good on mobile devices) like 1024x768 or the same width as containing div width/some height
2. or dynamically passed to the plugin.

In second case you would have to:

1. Do some screen resolution sniffing
2. Write it to some global variable/new plugin configuration variable/some other variable
3. Read it when toolbar button is pressed

[Piotrek Koszuliński]

Not a problem on IE8+ and we are not supporting IE7 any more.

[Danil]

On Google Chrome there is a slight delay (about 1s) on deep DOM (ExtJS App). As I see, ckeditor changes styles of each ancestor element. It's slow and potentially buggy.

Can I know why CKeditor devs does not use position:fixed?

[Jakub Ś]

Replying to danya_postfactum:

On Google Chrome there is a slight delay (about 1s) on deep DOM (ExtJS App). As I see, ckeditor changes styles of each ancestor element. It's slow and potentially buggy.

Can I know why CKeditor devs does not use position:fixed?

Have you perhaps tried same scenario outside of your application? It doesn't have to be CKEditor but some code in ExtJS or some third-party script that you use that conflict with CKEditor. Have you tried same steps to reproduce the problem in standalone CKEditor?
If you are able to reproduce the same in standalone editor could you provide exact step by step scenario to get it?

As I see, ckeditor changes styles of each ancestor element.

Please provide reduced HTML sample file that allows reproducing this problem in standaolne CKEditor plus step by step scenario to reproduce this problem.

[Piotrek Koszuliński]

Replying to danya_postfactum:

On Google Chrome there is a slight delay (about 1s) on deep DOM (ExtJS App). As I see, ckeditor changes styles of each ancestor element. It's slow and potentially buggy.

Can I know why CKeditor devs does not use position:fixed?

I guess that we don't use position:fixed for historical reasons. Now perhaps we could do that, because it would simplify the code a lot and perhaps made it faster.

Perhaps, because position:fixed is known for causing problems. And because I wasn't able to reproduce the issue. I attached 8587.html​ with CKEditor nested in 60 positioned divs. The only delay I see is on leaving maximize and it's caused by too heavy styling of the divs (border-radius and box-shadow) which affects entire page performance (e.g. scrolling in editor). This delay does not happen on 8587_2.html which has lighter styling. Of course, the delay would be lower if browser wouldn't have to rerender all those divs when leaving maximize, but in most cases it will have to do that anyway, because maximize needs to override <html> styles in order to get rid of scroll.

So, the situation is not so straightforward - changing the maximize behaviour perhaps makes sense because it may be beneficial, but that needs tests. I opened #11745.

[Danil]

I use Google Chrome.
I tested heavy.html page. Indeed, it get maximized fast, but there is a delay (about 400ms-600ms) before it get minimized.

I also found that delay strongly depends on plugin amout (or, I guess, toolbar complexity).

I use CKEditor in the MODx CMS. I made a "snapshot" of DOM, removed all scripts except CKEditor, and saved it as html. On full toolbar congif I get 180-250ms delay on maximizing, and 35ms on minimizing. When I use "standart" ​http://ckeditor.com/demo congif I get 50ms on maximizing.

I was wrong about 1s delay. My cpu: Intel Core i5-3210M 2.5GHz

Personally I don't care about these delays. I just wanted to let you know, that it exists not on IE only. Probably some computers works even slower. And I wanted to know reasons not to use position:fixed (thanks Reinmar)

[Danil]

ExtJS app (MODx CMS) HTML snapshot. See console.