Sometimes scrollbars show up on textarea

[bgrins]

Reported by @brianmhunt

http://jsfiddle.net/cBcTq/3/

[brianmhunt]

For a differential diagnosis between a textarea with scrollbars and one without see:

http://jsfiddle.net/cBcTq/6/

I don't know what's going on here that's keeping this from working, but I've set up the jsFiddle so that someone can perhaps tinker with it.

[brianmhunt]

It has just occurred to me that the solution may be as simple as overflow: hidden in the CSS for the textarea and clone.

This solves the problem for the http://jsfiddle.net/cBcTq/3/ example.

Before this is marked closed I'd like to do some more testing because I've happened on some cases where it doesn't solve the problem (i.e. there are no scrollbars, but not all the text is contained in the textarea). I'll try and set up another example.

[bgrins]

Oh yeah, thanks for the comparison demo. For some reason in my environment I had to bump the #hasbars from 350px to 360px.

The overflow hidden definitely seems to fix the problem, but I would prefer to not have to resort if possible since that could cause an issue if a bug happened and you couldn't see anything in the textarea, versus now where it is more of a cosmetic problem with the scrollbars.

[bgrins]

Still haven't quite figured out what is happening, but with a fork of the previous fiddle, I am showing the difference between the two (with the pre having red text): http://jsfiddle.net/bgrins/VVS4s/

The scrollbars throw everything off, so the issue is why they show up in the first place. Still looking into it.

[brianmhunt]

Me either. I emailed Neil Jenkins (sorry, I should have copied you - I'll forward it in a second, just so everyone's on the same page if he chimes in).

Oh - I completely agree about the overflow: hidden problem; mysteriously hidden text is worse than rarely getting scrollbars.

There may be two problems that are conflated:

1. Scrollbars sometimes appear (which makes diagnosing the second problem harder because scrollbars always appear when the second problem arises);
2. The height of the textarea is sometimes too short for the text.

To diagnose problem #2, we may have to add overflow: hidden; to the #hasbars textarea and come up with an example where the text overflows. The examples we have don't seem to exhibit this, however in a personal project I am getting problem #2.

I'll try and reproduce problem #2 and post it to your Fiddle so we can see what's happening.

[bgrins]

It's definitely funny - it is like the scrollbars showing up cause the measurements to be all wrong because of the extra 16px on the right that the pre has. However, the scrollbars shouldn't be showing up unless if the measurements are wrong in the first place.

[brianmhunt]

Okay, the issues I was having elsewhere were with incorrect textarea width by some bad css elsewhere interfering.

A good test would be to check that the textarea and pre elements were the same width and height.

I cannot reproduce the problem when overflow: hidden is set, which suggests that there's some problem with the browser tests as to whether the scrollbars are needed.

The overflow: hidden solution is a problem because it risks having information in the textarea unrendered and with no indication of its existence.

That being said, overflow: hidden is working for what I have now; I'll see if any problems crop up and report them if they do.

[bgrins]

Yeah, that is about as far as I was able to get on the problem too. I started a branch https://github.com/bgrins/ExpandingTextareas/tree/cleaner-css to try playing with different ways of storing the markup and CSS to see if it helped, but the same problem seemed to creep up. I might try to incorporate some of those changes into master anyway, but they definitely didn't fix this issue like the overflow: hidden; does.

I still don't really like the overflow hidden trick, but it is worth noting that this is used in the original article: http://www.alistapart.com/articles/expanding-text-areas-made-elegant/

[brianmhunt]

Neil Jenkins got back to me and confirmed that the overflow:hidden is necessary to avoid race conditions and rounding errors that could create unwanted scrollbars.

Here's what Neil wrote:

In regards to your issue, as you discovered, you should set overflow:hidden on the textarea when it is auto-expanding; otherwise you can potentially hit race conditions and rounding errors inside the browser rendering engines trying to work out if they need scroll bars. Providing the CSS is set correctly, the textarea will be the exact height required for the content, so the textarea never needs scroll bars.

That being the case, adding overflow:hidden to the textareaCSS should be sufficient to close this issue, wouldn't it?

[bgrins]

Thanks for following up on this. That should be enough to fix the issue in question, yes. The only thing I could see this messing up is the "max-height" example here: http://bgrins.github.com/ExpandingTextareas/.

[bgrins]

I suppose it could be an option to allow scrolling if you want the ability to set a max height

[brianmhunt]

Good point - this would break max-height. Maybe a line something like if (textarea.css('max-height') !== "none") { textarea.css('overflow', 'hidden') } could resolve this automatically.

Your suggestion to add an option permitting scrollbars is probably better - let the user decide.

Alternatively, you could make textarea.css(textareaCSS) not overwrite existing CSS (though I'm not sure offhand the best way to accomplish this).

[bgrins]

I was also just playing with this, and I found a fix (at least for the example you gave and in Chrome). By adding an extra line break at the bottom, it seems to not cause the race condition situation you refer from Neil. See this branch here (which has some other changes as well): https://github.com/bgrins/ExpandingTextareas/blob/cleaner-css/expanding.js. Not sure if it is a real solution (plus it adds an extra line to the bottom of the textarea that can't be removed).

[bgrins]

This actually seems to work now with no fix in the latest version Chrome. Maybe they fixed the race condition issue? Still an issue in Firefox though.

[domchristie]

I’m still experiencing this issue in the last version on Chrome.

Applying overflow: auto removes scrollbars by default in IE, so to develop @brianmhunt’s proposal, perhaps something like:

var hasMaxHeight = textarea.css("max-height") !== "none";
textarea.css({
  position: "absolute",
  // other textarea css declarations ...
  overflow: hasMaxHeight ? "auto" : "hidden"
});

It won’t be perfect (for max-height cases), but for any other case it’d be fixed

[domchristie]

Or how about listening to the overflow event? http://www.backalleycoder.com/2013/03/14/oft-overlooked-overflow-and-underflow-events/