Freezing on Chrome - Windows

[joaocunha]

I was not able to replicate the issue, but I got several reports of freezing on Chrome v43, Windows XP and 7. It happens while typing on it.

---

Edit: still not able to replicate the issue, but it seems the auto on height can be pretty expensive sometimes. I'm trying a few different strategies.

[joaocunha]

I tweaked the update() function to prevent constant recalculation. Indeed, it somewhat defeats the precision of the library, but it sorts this issue. This is what it looks like, now:

    function update() {
      var startHeight = ta.style.height;
      var htmlTop = window.pageYOffset;
      var bodyTop = document.body.scrollTop;
      var originalHeight = ta.style.height;

      // EDIT - set the textarea height to auto only if there was a change in
      // hard line breaks. Not ideal, but avoids doing it everytime, and it's
      // the performance bottleneck.
      var previousLineCount = autosize.lineCount;

      // Cross-platform line count
      autosize.lineCount = ta.value.split(/\r|\r\n|\n/).length;

      // Lines were deleted
      if (autosize.lineCount < previousLineCount) {
        ta.style.height = 'auto';
      }

      var endHeight = ta.scrollHeight + heightOffset;

      if (ta.scrollHeight === 0) {
        // If the scrollHeight is 0, then the element probably has display:none or is detached from the DOM.
        ta.style.height = originalHeight;
        return;
      }

      ta.style.height = endHeight + 'px';

      // prevents scroll-position jumping
      if (window.navigator) {
        var isMobileIE = (/IEMobile\/(\d+\.?(\d+)?)/.exec(window.navigator.userAgent));

        if (!isMobileIE) {
          document.documentElement.scrollTop = htmlTop;
          document.body.scrollTop = bodyTop;
        }
      }

      var style = window.getComputedStyle(ta, null);

      if (style.height !== ta.style.height) {
        if (overflowY !== 'visible') {
          changeOverflow('visible');
          return;
        }
      } else {
        if (overflowY !== 'hidden') {
          changeOverflow('hidden');
          return;
        }
      }

      if (startHeight !== ta.style.height) {
        var evt = document.createEvent('Event');
        evt.initEvent('autosize:resized', true, false);
        ta.dispatchEvent(evt);
      }
    }

[lighttroupe]

Hi João,

Thanks for this plugin!

We're using 3.0.5 and we've been hearing reports of high CPU usage and an "unresponsive page" popup from users on Chrome/Windows, I believe when they are typing into an autosize'd textarea.

Is this new update() going to be merged in, or would you like help in testing it?

[joaocunha]

Hey @lighttroupe! That was a rather hacky solution to prevent it from recalculating all the time. Think we should ping @jackmoore, the maintainer of the library, about this.

[jackmoore]

@lighttroupe I don't have any plan on merging this in. Counting new-line characters is a poor way to figure out how tall the textarea should be because it doesn't account for line wrapping. You should use replace 3.0.5 with the current version, it includes bug fixes and performance improvements.

@joaocunha Thanks for the feedback. Since this was posted there have been some minor optimizations, but they don't really fix the root problem of switching to height auto being intensive. I think the only good alternative to that is mirroring the text in an on offscreen textarea element instead, but that brings it's own problems. With the mirror element, the code is more complex due to copying with accuracy all size-impacting textarea layout and typographic styles onto the mirror element. This is not a one-and-done deal because the way to get those styles is to use getComputedStyle, which returns the computed styles, these need to be re-checked constantly in case they've changed. The old version of autosize worked that way, but I don't want to go back to that.

I intended for Autosize to be a drop-in script for anyone's website, which puts a lot of burden on the script to calculate the exact size with limited information. If you were building a high-budget site, like a Github or StackOverflow, I think it would be best to use the mirror element. You could skip a lot of complexity with the outside knowledge of exactly what styles the mirrored element should have, and what events, if any, might cause them to change.

Or possibly replace textarea elements with a contentEditable div. Replacing textarea elements with contentEditable is way outside the scope of this script, but it's an approach I would seriously consider if I needed expandable input on one of my own sites.

[lighttroupe]

OK I'll upgrade and see what effect that has.

Related, would it make sense to upgrade the version used for the demo here? http://www.jacklmoore.com/autosize

It would be nice to be able to send people there for testing.

Thanks Jack!

On Wed, Jan 6, 2016 at 11:13 AM, Jack Moore [email protected] wrote:

@lighttroupe https://github.com/lighttroupe I don't have any plan on merging this in. Counting new-line characters is a poor way to figure out how tall the textarea should be because it doesn't account for line wrapping. You should use replace 3.0.5 with the current version, it includes bug fixes and performance improvements.

@joaocunha https://github.com/joaocunha Thanks for the feedback. Since this was posted there have been some minor optimizations, but they don't really fix the root problem of switching to height auto being intensive. I think the only good alternative to that is mirroring the text in an on offscreen textarea element instead, but that brings it's own problems (code complexity and accuracy of size-impacting textarea layout and typography ). The old version of autosize worked that way, but I don't want to go back to that.

— Reply to this email directly or view it on GitHub https://github.com/jackmoore/autosize/issues/241#issuecomment-169424534.

[jackmoore]

@lighttroupe Updated

[balazs-endresz]

I don't have this issue any more after upgrading to 4.0.2 from 3.x.

[jackmoore]

@balazs-endresz Thanks for the followup, that's good to hear.