Autogrow does not work in tabs

[Scott]

Steps to reproduce

1. Set up multiple CKEditors in tabs.
2. Turn on AutoGrow plugin.
3. Switch tab.

Expected result

All CKEditors to be the correct height to fit the content.

Actual result

In Chrome: the editor expands MASSIVELY to be > 32000px tall. In Firefox: the editor does not expand at all.

Other details (browser, OS, CKEditor version, installed plugins)

Demo: ​http://85.159.215.184/cke-grow/

Latest CKEditor, 4.5.7. Tabs are using latest Twitter Bootstrap, 3.3.6. CKE config file is here: ​http://85.159.215.184/cke-grow/static/js/ckeditor-config.js

[Jakub Ś]

Yo need to focus editor so that autogrow could kick-in. It works correctly in Firefox. Once you click (there is also editor.focus() method) editor expands correctly.

I'm not sure about chrome. In my case editor height is 71503px but as I have said before, the autogrow kicks in once editor is focused and here editor gets expanded right after opening the tab.
Are you setting the height once tab is opened? If there is no code changing the height, does the same happen when you open Tab 2 as the first one?

[Scott]

It works correctly in Firefox.

It doesn't for me. As I said it doesn't expand when it should do. In other words, the content in the second tab is longer than the first so the editor should expand to fit that content.

Are you setting the height once tab is opened?

No. The height is already set by CKEditor. When you first load the page, before clicking Tab 2, check cke_2_contents in dev tools, it shows

<div id="cke_2_contents" class="cke_contents cke_reset" role="presentation" style="height: 71503px;">

If there is no code changing the height, does the same happen when you open Tab 2 as the first one?

When Tab 2 is set as the active tab to start, it expands to the correct height, then when switching to Tab 1, the editor in that tab is now huge.

I have used .focus() as a workaround for now, but needing to do that still feels like a bug to me.

[Jakub Ś]

I have used .focus() as a workaround for now, but needing to do that still feels like a bug to me.

No. Please read what I have written before. Autogrow starts when you focus the editor. This is how it works by design. You need to click into editor or use editor.focus() to make autogrow work and that is no bug. Firefox works just fine - you open tab, you click and then it expands.
Most users like the default behaviour, some don't and for those there is the editor.focus().

When Tab 2 is set as the active tab to start, it expands to the correct height, then when switching to Tab 1, the editor in that tab is now huge.

Could you just clarify if the second tab set to active auto-expands or you need to click into editor (or use focus method)?

The behavior in Chrome is very weird but since this is happening with tab which should not grow you should also check if none of your scripts is causing this or none of your scripts together with the autogrow.
Could you make simple test - disable autogrow, clear browser's cache (​this is not Ctrl+F5) and re-check?
Perhaps there is a script in your application which tries to remember the current height but something goes wrong in the calculations and you end up with such a huge content area?

[Scott]

I have the setting config.autoGrow_onStartup = true; in the config, so autogrow is supposed to work without needing the click first.

Could you just clarify if the second tab set to active auto-expands or you need to click into editor (or use focus method)?

It auto-expands to the correct height on page load, in both Chrome and Firefox.

[Jakub Ś]

Editor content area doesn't auto-expand by default and we are not going to change that.

It auto-expands to the correct height on page load, in both Chrome and Firefox.

I don't think this is the answer to my question especially because you claimed that it doesn't work in Firefox in last post.

When you had first tab set as active in Chrome, it opened normally and second tab was auto-expanding too much. This wasn't normal because autogrow doesn't do that by default. You have then set second tab to active and you have written that it expands correctly but now your first tab expands too much.
I wanted to know if second tab when set as active (when page loads) auto-expands or do you need to click on it or use focus method. I wanted to make sure that autogrow work by design in this case.

[Scott]

I don't think this is the answer to my question especially because you claimed that it doesn't work in Firefox in last post.

I said that when opening the *second tab*, the editor doesn't expand. The active tab expands to the correct height on page load, in both Chrome and Firefox.

I wanted to know if second tab when set as active (when page loads) auto-expands or do you need to click on it or use focus method.

Yes, when the second tab is active by default, it expands to fit the content fine. I've updated the demo to set the second tab as the default. In both Chrome and Firefox, it expands to fit the longer content. But then clicking Tab 1, I get the same problems again - the editor in Tab 1 expands massively in Chrome, and doesn't expand at all in Firefox.

Hope that makes everything clear.

[Jakub Ś]

First of all I need to apologise for giving you invalid information. I mixed up few facts together and ended up with some false information that you need to focus editor to get autogrow working.

Now this is true but if you set autoGrow_onStartup : true then editor will adjust its height on instance creation - ​http://docs.ckeditor.com/#!/guide/dev_autogrow-section-height-adjustment-on-startup.

Whenever you set first or second as active it will load and editor height will be adjusted. Contrary to what I have said earlier this is correct. Now the problem is the second tab. From what I have checked the content area is either too small or too big but if you click into editing area the height will be adjusted.

This means that autogrow plugin works as expected (when you look at plugins default behaviour) but autoGrow_onStartup doesn't kick in. Now the real problem is that height either can't be calculated or is calculated incorectly for element with style display:none and this is what is happening in case of inactive tab. To solve this problem I would suggest to load the second editor (from inactive tab) when it is being viewed for the first time.

NOTE: When I removed autoGrow_onStartup and set autoGrow_minHeight to 200 I ended up with both tabs loading as to small but gaining correct size once editor was focused. Since it works correctly (I'm talking default behaviour) it is possible that autoGrow_onStartup calculates the height for editor in display:none tab incorrectly. I'm not sure however if there is anything editor can do here. I don't imagine autogrow searching DOM for display:none parent element and making them visible until it calculates the height.
This is IMO rather a matter of loading the instance once tab is shown for the first time or making the inactive tab visible (for example off screen) until height is calculated.

[Marek Lewandowski]

Sure, the problem here is the fact that editor is not displayed. Current behavior in fact looks buggy.

Now, currently content height is calculated by putting a block element (actually span with display:block) at the end of body (or documentElement, which is rather hack in some cases) and then it calculates the offset of inserted element from the top of the doc.

Major changes in a way that autoGrow plugin determines the height might be very tricky (risky), but we should do something to overcome this enormous height being applied.

What we can actually do is to check in autoGrow if the editor is displayed - if not, then just leave the default height. Height will be adjusted as soon as one focuses the editor which is fine.

Let's see if we can put it next release.

[Tade0]

Changed the autogrow behaviour so that even if the autoGrow_onStartup config option is set to true the editor does not change its size if the editable is not visible.

Added manual test for this ticket.

Changes pushed to: ​branch:t/14413.

[kkrzton]

This fix looks good and works for all browsers but IE8. The editor in the first tab still has this enormous height. I am not sure if it can be fixed for IE8 but we should check for possible solutions (it seems editor.editable().isVisible() does not work in this case and returns true for Tab 1 so it works same as without the fix).

[Tade0]

I guess the only way to solve this then is to get rid of the root cause, by which I mean the wrongly reported height of the hidden editor.

[kkrzton]

Replying to Tade0:

I guess the only way to solve this then is to get rid of the root cause, by which I mean the wrongly reported height of the hidden editor.

@Tade0 I think that may be the proper solution. As I mentioned above also editor.editable().isVisible() does not seem to work in this case, but I assume fixing it won't help if height is still incorrectly calculated.

[Tade0]

I may have found the root cause of the problem: It seems that IE8 is trying to wrap text in a zero-width element this way producing a very high and narrow column of characters.

I have a few ideas how this can be solved so I'll try them now.

[Tade0]

Manipulating styles and the width of the elements helped somewhat, but did not solve the problem. Instead of getting values in the millions I was getting values in the tens of thousands - still an order of magnitude too high.

As a last resort approach I simply assumed, that since getBoundingClientRect is not reliable in IE8 then it should not be used at all, and added an appropriate check.

Looks like this approach works.

Changes pushed to ​branch:t/14413.

[Tomasz Jakut]

I've reorganised tests a bit.

Fixed with ​git:b3d6b0ac5a3e1dc008c087baef2d2c15ccf6a03d.