Progress not set correctly when exceeding textarea max character limit (demo)

[ConnorKrammer]

Small issue with the progress bar not filling all the way on repeated text input.

To reproduce:

1. Focus the textarea demo.
2. Type until the progress bar is 3/4 full.
3. Stop, and note that the progress bar does fill up correctly.
4. Now switch to a new line, and hold down any key. Characters will be inserted as long as the key is held down, and extra characters will be erased on keyup. However, the progress bar will not update correctly to 100% in this scenario.

---

On a related note, it might be prudent not to allow characters to be inserted at all if the character limit is exceeded -- binding to the 'keypress' event and disallowing any keypress except the backspace key would work. Something like:

var maxChars = 200;
var keyCodeBackspace = 8;
var keyCodeDelete = 46;

// Prevent input when textarea character limit exceeded. Allow deleting characters.
textarea.addEventListener('keypress', function(event) {
    if (textarea.value.length >= maxChars
      && event.keyCode !== keyCodeBackspace
      && event.keyCode !== keyCodeDelete) {
        event.preventDefault();
    }
});

[amerryfellow]

IMHO, this issue can be solved by just adding a "prgjs.set(100);" in the second branch of the textareas if construct in demo.js: this has little to do with progress.js itself.

--- /tmp/demo.js
+++ /tmp/demo.js
@@ -145,5 +145,6 @@
     prgjs.set(this.value.length);
   } else {
     this.value = this.value.substring(0 ,100);
+    prgjs.set(100);
   }
 };

[ConnorKrammer]

That would fix the progress bar not setting correctly, but it wouldn't fix how the text "snaps" back when you let go of the key. Try holding down the key past the limit then letting go -- the extra is just lopped off abruptly, and the original cursor position lost. This is because the textarea is actually having its contents reassigned to the substring of the previous contents, which does not preserve cursor position (the lopping is because it doesn't trigger until the keyup event). A better option would be to prevent the characters past the limit from ever being inserted into the textarea by using event.preventDefault() on the key event. Mind you, you'd have to be careful not to prevent backspace, delete, or meta-key combinations from working, but that would solve the problem.

@h3st14 You're right when you say that the issue isn't with progress.js itself -- but I'm a designer as well as a programmer, so the usability of the demo just stuck out at me. Having a good demo is important, as it shows to potential users that the problem isn't with progress.js, something they might not realize.

[ConnorKrammer]

Goddammit, I hate when I accidentally close things.

[amerryfellow]

I'm not sure that is the optimal solution: what if I want to insert "aaaaa" by holding my "a" key: that would be prevented, wouldn't it?

Maybe the best solution is the trivial one: Setting the "maxlength" attribute of the textarea appropriately would prevent the user input after the maximum number of characters had been reached.

However, I agree that some work to "make things easier" could be done. I'll take a more thorough look at the code.

[ConnorKrammer]

Ah, I didn't mean to say block all repeated characters, just the ones
after the character limit has been reached.

One of these days when I've got enough time I'll fork the repo and write a
pull request (if you don't do it first).

Sounds good!
On Thursday, February 27, 2014, Andrea Paternò [email protected]
wrote:

I'm not sure that is the optimal solution: what if I want to insert
"aaaaa" by holding my "a" key: that would be prevented, wouldn't it?

Maybe the best solution is the trivial one: Setting the "maxlength"
attribute of the textarea appropriately would prevent the user input after
the maximum number of characters had been reached.

However, I agree that some work to "make things easier" could be done.
I'll take a more thorough look at the code.

Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-36224829
.

[afshinm]

@ConnorKrammer Everything goes well now?

[afshinm]

Thanks for the help @amerryfellow 👍

[ConnorKrammer]

@afshinm I've opened a pull request that should solve the above issues fairly well. Let me know if it works for you, and if anything needs to be changed.