>>>Think you're right. One thing to check : Is currentSpecial.discFlat in your model a number. If it's a string I think it could cause the error - see:
>>>https://docs.angularjs.org/api/ng/input/input%5Bnumber%5D
>>>
>>>>What is your angularjs version?
>>
>>discFlat originally comes as a number. However, if you look closer at the smNumberFormat directive you'll see that we're using $filter service and it returns a string.
>
>Hmm. Could be wrong but it seems to me that if you are using 'type="number"' then angular won't allow commas anyway so that filter is redundant ?
>
>>So, in my opinion, if I can get the inputNumber directive apply first and then smNumberFormat, it would solve the problem. I was thinking that adding negative priority should solve the problem, but it didn't.
>>
>>So, after the number goes through the smNumberFormat directive, it comes as a string to the inputNumber check in the new angularjs and this is where it gives the error.
>>
>>I am wondering why do we need to check for the actual number and not the string number here? That's why I think it's an issue and I posted it here
>>
>>https://github.com/angular/angular.js/issues/11157

OK. I *think* I see what's happening. In summary:

At the moment your formatter is first in the pipeline. It converts the number to a string which is passed to the angular 'number' formatter. Since this is expecting a number it bombs.

But you really want your formatter to run *after* the angular formatter (so it can strip the commas that are present) and, since it will get it's value as a string it would need to be rewritten accordingly.

UPDATE: I see it is expecting a string so forget the last bit.

What I'm not sure about is how you ensure your formatter is second in the chain.....

UPDATE2 : Duh. I now see that's what you were trying with negative priority. Did you check the actual order obtained in that case ?