Re: [chromium-discuss] Change to validation order in Chrome 51?

[Rick Byers]

Sorry to hear that this change in behavior has caused trouble for you!

+chongz and dtapuska (on input-dev) who have been doing some work with 'input' events recently.  I don't recall there being an intentional change here, but I may be forgetting.  You said there was a bug filed, right?  What's the ID?

On Fri, Jun 24, 2016 at 5:38 PM, Nance, Aaron <aaron...@pearson.com> wrote:

No offense taken. Just pointing out I've been doing this awhile and know the best practices and I know they have to be balanced with a practical approach when the best practices fall short  I don't know if you have used IME, but it is the reason we started leaning on maxlength. We didn't want to write the large amount of code that would be needed to deal with composition events. If you're not familiar with IME it is used to enter foreign languages. When doing many of the Asian languages that require multiple keystrokes per character, such as Japanese Katakana, keydown is not a good option.

On Fri, Jun 24, 2016 at 4:21 PM, PhistucK <phis...@gmail.com> wrote:

​​

On Sat, Jun 25, 2016 at 12:02 AM, Nance, Aaron <aaron...@pearson.com> wrote:

As a side note, I actually do check a set of features to determine is a browser is webkit/chromium, firefox, edge or IE. All browsers have feature fingerprints.

​That is also bad, features change and you cannot assume that just because a browser has feature X, Y and Z, it means it is Chrome.

This is exactly how document.all got into the specification in a terrible way (document.all must exist, but its typeof must be equal to "undefined"​) and exactly how it screwed Internet Explorer 11 when it implemented standards (addEventListener, for example).

 I know how to write the code to do enforce a given length. I've been using JS since 1996.

I was not suggesting otherwise, I am sorry if I came across that way. I suggested another event which might guarantee the order your want, since it is completely standardized already and should not change, unlike input which is relatively new (relative to keydown, that is).

Rick, do you happen to know whether the order of the input event and the validation phase has intentionally changed?

☆PhistucK

--

Aaron Nance

Software Developer

Assessment & Instruction

Pearson

E: aaron...@pearson.com

Pearson

Always Learning

Learn more at www.pearsonk12.com

[Chong]

Sorry for the confusion! Actually it's not related to 'input' events order.

 

I suspect it's caused/fixed by https://crbug.com/592448, +tkent for more information.

Disclaimer: I'm not an expert on TextArea :)

IIUC Chrome <51 counts existing newlines in |value| as 2 against |maxlength|, but forgot to count those in new texts. e.g. New newlines from 'Enter' key or paste.
Which means with |maxlength==3| you can type 2 letters + 1 newline, or 1 newline but only 1 letter.

After Chrome 51 we also count new texts, so you can only have 1 letter + 1 newline no matter who goes first, and this seems to be a reasonable behavior.

Possible workaround:

'textInput' is fired before validation and contains the text to be inserted, maybe maintain |maxlength| based on 'textInput'.data?

Note:

1. 'textInput' is not standardized and only available on Chrome and IE, 'beforeinput' should be a better option but it's not available yet.

2. 'input' won't work because it's always after validation.

[TAMURA, Kent]

On Sat, Jun 25, 2016 at 1:02 PM, Chong <cho...@chromium.org> wrote:

Sorry for the confusion! Actually it's not related to 'input' events order.

 

I suspect it's caused/fixed by https://crbug.com/592448, +tkent for more information.

Disclaimer: I'm not an expert on TextArea :)

IIUC Chrome <51 counts existing newlines in |value| as 2 against |maxlength|, but forgot to count those in new texts. e.g. New newlines from 'Enter' key or paste.
Which means with |maxlength==3| you can type 2 letters + 1 newline, or 1 newline but only 1 letter.

After Chrome 51 we also count new texts, so you can only have 1 letter + 1 newline no matter who goes first, and this seems to be a reasonable behavior.

Yes, this was what we changed in Google Chrome 51.

We didn't change the order of maxlength user-input restriction and input events.  The restriction has been done before input events for years.

The behavior of Google Chrome 51 conforms to the HTML specification.  IE, Edge, Firefox, and WebKit don't conform unfortunately.  WebKit counts an EOL as 2, but it counts grapheme clusters instead of code units.

I understand counting an EOL as 1 is common demand.  We should propose a specification change.  For example adding maxlengthmode=codeunit|codeunit-api|codepoint|codepoint-api|grapheme|grapheme-api

--

TAMURA Kent
Software Engineer, Google

[Nance, Aaron]

Thanks for the info about the bug and the clarification. 

I agree that the standard should be changed. While the other browsers aren't conforming to the WHATWG standard in this case their behavior is much more logical. What I, and a lot of other devs out there, want, is consistent counting behavior between the browser maxlength and javascript text length It is insanity inducing to get different values depending on how you look at the same data.

None of the workarounds mentioned will work for the situation where there is one character left and the user presses enter. I tried them all before I posted here.  This will just have to be a known issue in our software, albeit a minor one. 

[TAMURA, Kent]

I have filed a specification issue: https://github.com/whatwg/html/issues/1467

[Nance, Aaron]

Thank you, Kent! That is s great writeup of the issue.