Autogrow usability

[Garry Yao]

This's a continuation of #6408, where the "autogrow" plugin is still inconsistency in some situation:

1. Load the editor (with "autogrow" plugin) with a long time in <pre> in order to display the h-scrollbar.
2. Put in more stuff until the auto growing happens.
   • Actual Result: Vertical scrollbar is still there

And it even introduce an usability issue on Webkit:

1. Load the editor (with "autogrow" plugin) in Webkit;
2. Put in more stuff until the auto growing happens.
   • Actual Result: Host page scroll up whenever the auto growing happens.

[Garry Yao]

The resizing logic is rewritten by this patch that makes it easier to adapt to cases when having scrollbar.

[Dinu]

Doesn't work quite as well as the previous version:

• The minimun delta of 18: not a good idea, because 1) it constantly triggers toolbars and 2) I have this use case: I use the editor to replace divs and I set the initial height of the editor to the div height. The delta for the first trigger is never 18 (usually 2-4 px accounting for table lines) so the editing almost consistently starts with scrollbars. Removing the >18px condition produces good results.
  
• There is a flicker on Webkit when either the first or the last paragraph has a margin that is taller that body margin (just go to end of document, add a 50px margin paragraph, go back to wysiwyg and press down arrow a few times, height will cycle)
  
• IE: it's always oversized 28px, even in standards mode (IE8) and it cycles like Chrome in IE7 even without margins
  
• in Opera it works flawlessly (but the editor is broken...)
  
• Mozilla: constantly 28px overtall

[Dinu]

Please mind I'm using 0px body margins and is the best way to test, having higher margins for body can hide some flaws.

[Garry Yao]

Polishing the patch targeting the above tests from dinu.

[Dinu]

I don't know, but for me this just keeps growing, and growing, and growing... in Chrome, Mozilla and IE...

[Dinu]

Screenshot attached... (sorry for size). It seems that:

• The cke_contents td is not resized properly (notice the scrollbars)
• The span that you see below in firebug just keeps growing (height is set to incresing size without reason)

[Garry Yao]

We'd love to receive comments from a real world app, no problem, but would you mind of creating a reduced TC that's accessible for every body?

[Dinu]

Sorry, my bad (I think). I applied the patch to 3.5.1; on the nightly build it works, and it works great! Here's the only glitch I could find:

• make an editor with fixed width (say 600px) and 0px body margin
  
• insert an element that is wide enough to not allow for vertical scrollbar (eg a table w/ 595px width)
  
• as the area autogrows, it's constantly 1 srollbar higher than it should, in IE8 and FF
  

I think, the above can be fixed like this: if the contents' scrollWidth (or whatever quirks equivalent) is smaller than the editor width, temporarily set overflow:hidden while autogrowing. Just a thought, haven't really worked it out.

Other than that, it's excellent and works like a charm.

[Dinu]

One more problem on webkit:

• add at least 2 paragraphs of text that are longer than 1 line (wrap) and high enough to trigger autogrow
  
• editor will flicker

[Frederico Caldeira Knabben]

Please just rename the "resizeContents" parameter to "forContents". It took a while for me to understand it. It would be good to have its documentation in place as well.

@dinu, i was not able to reproduce the webkit issue. I found the description a bit confusing, so maybe I've missed something. Please feel free to open a dedicated ticket for it with more details. Thanks.

[Garry Yao]

Fixed with [6921].

[Dinu]

Yeap, WFM too in 11.0

[Dinu]

(Chrome) and 5.0,5 (Safari). Sorry for the fragmented post, I tripped over submit button.

[Wiktor Walc]

Reverted with [7056].

[Jakub Ś]

Scrollbar is present on in IE6 and IE7 while other browsers show it only for a moment and then hide (I think this part is ok).

This issue is reproducible from CKEditor 3.4.

Note about Webkit duplicates #6540.