Placing textarea at a lower point in the document causes scrolling issues

[fmal]

See: http://jsfiddle.net/nh90hvhe/1/

When you type some lines of text, the size of the textarea grows longer than the browser window. At that point the top of the window jumps to the top of the textarea every time a key is pressed, which is extremely annoying for the user.

[javierjulio]

👏 nice discovery! Thanks for sharing. I took a quick look and see the bad behavior (Safari on Yosemite). I'm not sure when I'll have time to dig further. If you have some suggestions on how to fix/handle this I'm all ears.

[JohnNmiMa]

Anyone get a chance to fix this? My code was working great with textarea-autosize, and then I tested as fmal discovered. It is quite annoying.

[javierjulio]

@jettagozoom @fmal I looked into this and figured the only solution I could think of is maintaining the window scroll top position before the textarea height is reset and then restoring the scroll position. I have a passing test. I've committed a change. Let me know how that works out for you before I push out to bower/npm. Thanks!

[JohnNmiMa]

Hey Javier,

Good job - your fix works great on my app. You don't know how many
solutions to the expanding textarea that I've tried. Your's is certainly
the most elegant, clean, and performant. It doesn't jump around or create
those pesky shadow textareas.

Check it in as far as I'm concerned,
John

On Tue, Dec 16, 2014 at 11:45 AM, Javier Julio [email protected]
wrote:

@jettagozoom https://github.com/jettagozoom @fmal
https://github.com/fmal I looked into this and figured the only
solution I could think of is maintaining the window scroll top position
before the textarea height is reset and then restoring the scroll position.
I have a passing test. I've committed a change. Let me know how that works
out for you before I push out to bower/npm. Thanks!

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[fmal]

Thank you for taking time to fix this. This doesn't account for situations where the textarea is inside a scrollable element (not document) though. Say you have autosizing textarea within a <div> with overflow property to trigger scroll - getting the window offset won't do the trick in this case.

Maybe there should be some option like:

var element = options.closestScrollableParent || window,
    $element = $(element),
    currentScrollPosition = $element.offsetTop;

      // ...

    $element.scrollTop();

I'm not happy with this solution though as you would need to manually specify something based on textarea's placement 😕

edit: seems like jQuery UI has a proper method for automating this: http://api.jqueryui.com/scrollParent/, but it means having to do some pesky dom tree traversal

[javierjulio]

@jettagozoom thanks! Yes those are some of the exact issues I had when looking for a solution. I'm glad you've found it useful. 😄 I will deploy a patch release shortly.

@fmal yes the DOM traversal is concerning on every update. The scrollParent method seems rather self contained so adding it in here shouldn't be much of a problem but I'd like to see if we can do something else. If anything I don't see an issue with a variation of your solution but instead you specify an optional selector for the closest scrollable parent. What do you think? Sure the plugin is great without any options but at some point that is inevitable. Its so great to learn how you are all using this! I didn't expect such situations to arise. Let me know what you think.

[fmal]

I've done some testing and it turns out that this scrolling issue is partly caused by triggering both input and keyup events. Removing keyup event minimizes the issue on Chrome. Replacing .height('auto') with .height(0) makes IE 11 shrink textarea when deleting text, so i'm not sure whether keyup is really necessary.

[javierjulio]

@jettagozoom @fmal I released 0.4.0 with several changes including these. I forgot to remove the keyup event but I did change it to height(0) instead. I believe I had keyup there because last time I tested on IE was for version 9 and 10. I don't have access to those versions at the moment though, only IE11 as you tested. I noticed that it works fine but sometimes has a little flicker in IE11 now.

[alexkravets]

I'm having this issue with the latest 0.4.0 version in Chrome. When window is scrolled on a keyup event it's just scrolled to the top, parent div is absolutely positioned in full height.

[alexkravets]

Here is solution that works for me, this includes standalone scrollParent plugin (https://github.com/slindberg/jquery-scrollparent):

    var $scrollParent = $(this).scrollParent();
    var currentScrollPosition = $scrollParent.scrollTop();

    $(this)
      .height(0)
      .height(this.scrollHeight - diff);

    $scrollParent.scrollTop(currentScrollPosition);

Posting it here in case someone needs a working solution asap.

[maxnowack]

+1

[KristerV]

in my case the height(0) causes the screen to jump and scroll to the cursor out of the view if textarea is higher than screen. Si I removed it.

[d2a-raudenaerde]

I added a .focus() at the end, seems to help my scrolling problems in IE.

  this.$element.on('input keyup isselectedbyuser', function(event) {

	if ($(this).height()!=this.scrollHeight - diff) 
	{
    $(this)
      .height(0)
      .height(this.scrollHeight - diff).focus();
	}
	
  });

[AndiZ23]

I replicate this issue when the textarea is at the bottom of a scrollable document. The page got scrolled to the top everytime when the textarea's size is changed.
But I fixed that with scrollIntoView(false) under input and keyup event listener:

$("textarea").on("input keyup", function () {
      var $bottom = $(this).next();  // there should be an element under the textarea, otherwise, use $(this)
      $bottom[0].scrollIntoView(false);
 });

For Chrome, just using keyup is fine, while for IE 11, using input as well will prevent the document from being flashing when a key is pressed into this textarea.