fix(input): by default, do not trim input[type=password] values

[caitp]

Previously, all input types using ngModel and textInputType() would trim values if the ng-trim attribute was unspecified. This is undesirable for passwords because a user's input should always be canonical in that case.

This CL changes this behaviour by only trimming by-default if the input type is not password. In the future, if other input types need to be checked, or if the input type needs to be checked at runtime, this may be refactored to support those cases.

BREAKING CHANGE:

Previously, input[type=password] would trim values by default. This is no longer the case, and requires an explicit ng-trim="value other than 'false'" to ensure that the value is trimmed in casees where this is actually desirable.

Example:

<!-- WILL NOT TRIM VALUE -->
<input type="password" ng-model="password">
<input type="password" ng-model="password" ng-trim="false">

<!-- WILL TRIM VALUE -->
<input type="password" ng-model="password" ng-trim="ANYTHING ELSE"> 

Closes #8230

[mary-poppins]

Thanks for the PR! Please check the items below to help us merge this faster. See the contributing docs for more information.

• Uses the issue template (#8250)

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[Narretz]

I don't really understand why we need this change. Are there password with leading / trailing whitespace?

[caitp]

good question, but who cares!

[IgorMinar]

oops.. we never thought about trimming and passwords. this is definitely a fix that should be backported to 1.2.

But does it make sense for passwords to ever be auto trimmed? in which case do we even need to support enabling the trimming? It looks like dead code to me. I suggest removing it and just documenting that trimming is not supported for input[type=password].

[caitp]

sounds good to me

[caitp]

Changed to never trim if the input type is 'password'

[caitp]

PTAL --- are we good to check this in for beta 18?

[eekboom]

Unfortunately this is yet another change, that causes me additional work instead of simplifying things.

I understand the rationale to not trim password fields by default.
But who are you to decide that no user of angular would ever want to have password fields trimmed?
We have an explicit requirement from our users to do so to avoid locked out users that have accidentally added a space to their passwords.

I think angular js itself should also be driven by actual user requirements.
Or maybe I missed a discussion somewhere?

Another argument is the "principle of least surprise": If I add ng-trim="true" to a password field, it should not be silently ignored.