custom directive and ng-pattern interfere in rc.2

[mblase75]

http://plnkr.co/edit/dbvC9NWcZTpWRRiUTkJU?p=preview

A custom directive (to convert a text input to all-caps as the user types), combined with a ng-pattern for validation, prevents any text from being entered into the text input.

Key HTML:

<input type="text" ng-pattern="/^[a-zA-Z]{2}$/" name="CustomerState" ng-model="customer.CustomerState" required allcaps>

JS:

'use strict';
var app = angular.module('app', ['ngRoute']);

app.directive('allcaps', function() {
// use in input fields as an HTML attribute to capitalize ALL input before sending to the model:
// <input type="text" name="JobCodeCode" ng-model="quote.JobCodeCode" capitalize>
// copied from: http://stackoverflow.com/a/16388643/901048
return {
    require: 'ngModel',
    link: function(scope, element, attrs, modelCtrl) {
        var allcaps = function(oldstr) {
            if (oldstr == undefined) { oldstr = ''; }
            var newstr = oldstr.toUpperCase();
            if (newstr!==oldstr) {
                modelCtrl.$setViewValue(newstr);
                modelCtrl.$render();
            }
            console.log(oldstr+","+newstr); // outputs capitalized characters as I type
            return newstr;
        }
        modelCtrl.$parsers.push(allcaps);
        allcaps(scope[attrs.ngModel]);  // capitalize initial value
    }
};
});

In rc.2, I type in the text field and nothing appears. This code works fine in rc.1 and previous versions.

If I remove either the custom directive JS or the ng-pattern attribute, the text field displays text again in rc.2

[shahata]

This is because the value passed to your parser is undefined because it is invalid (pattern requires two chars, so the first char is always invalid)
You can fix that by using ng-model-options="{allowInvalid: true}". Fixed plunkr: http://plnkr.co/edit/l8CjOdmRVVU52lklntkd?p=preview

[caitp]

did we ever mark that as a breaking change? I know someone asked for it to be documented in the changelog

[mblase75]

Is this an identical issue to #8290 then? I would have liked to see it in the changelog as well.

[btford]

@caitp sadly, no.

@mblase75, @shahata – would either of you like to submit a PR to add this to the changelog? :D

[mblase75]

I'm still too new to do it correctly. :-/

[caitp]

I'm not sure when we changed this --- it might have been db044c4 but I'm not positive. If I can sort out when this broke I'll make sure it's documented

[Narretz]

Throwing another hat into the ring: the actual cause is 3e51b84

$render now checks if the $modelValue is empty before calling val() with the $viewValue. This doesn't really make sense, or rather it locks $render into a single use case, model -> view updates. If we want to check for empty values before rendering, we need a different way.

What happens in the issue here is that $render sets the input to empty string, but the $viewValue stays correct. This confuses the whole processing.

Imo $render should be dumb and only set the .val()

[Narretz]

This is fixed in 1.3.4 :)