Textarea scroll-as-you-type not working properly

[obermillerk]

Hi, We have a text area that we style to be a certain height to line up with the rest of the page. The problem is that when using this plugin to type, the text area will not scroll properly. If I remove the height styling, the scrolling works as intended when the rows attribute is 7 or higher. With the height styling, the scrolling seems to be based on an assumed value for the rows attribute. It will scroll eventually, but it seems to assume that there will be at least 7 lines visible, and so only scrolls once there is an 8th line. This behavior doesn't even make sense, because I have the rows attribute on the text area set to 4.

Something truly bizarre is that if I click in the keyboard container (not on any keyboard key) it scrolls to where it should be. If I then click a keyboard button, or even click out of the textarea (closing the keyboard) it scrolls back to it's improper location from the behavior described above.

Now, I attempted to make a fiddle demonstrating this, but it actually worked fine on the fiddle, so I was more just hoping you could help me figure out what might be going wrong. At least, what attributes/css properties are used in the scrolling behavior? We have other textareas in almost identical contexts that work totally fine with your plugin, so I'm really not sure what's happening with this one.

[Mottie]

Hi @obermillerk!

Internally, there is code that constantly adjusts the scroll left (inputs) and top (textarea) position (see setScroll code) to ensure that the caret is always visible. I'm not sure why there's an issue within textareas when height is below a certain amount. I'll need to review the code that checks the caret position and element's height.

I set up this demo that'll allow you to tweak the behavior of the setScroll function (around line 75) and hopefully help me narrow down the problematic code.

[obermillerk]

I think I may have discovered the cause. The width of the text area is being set as 100%, but when this is cloned to get the height, the width is maintained as 100%, which ends up being much wider and thus it would take much more text for it to increase the number of lines, making it's scrollHeight inaccurate.

EDIT: This could extend to padding as well, which I believe is included in scrollHeight

EDIT 2: Updated fiddle that exhibits the behavior.

EDIT 3: I think font-size could also affect this issue. I've noticed that the previewCopy is being prepended to the keyboard element, which has a different font size specified than the default. Since we don't modify the font-size of our text area with any styling, it uses the default browser styles, which is overwritten by the keyboard's styling.