-
Notifications
You must be signed in to change notification settings - Fork 27.5k
<input type="number" max="{{max}}"> does not set $error.max property #2404
Comments
this is possibly related to issue #2144 - there clearly are some issue with cross-browser input type=number.. :( |
I think the parseFloat line should be moved inside the maxValidator function. The interp seems like it's already being done beforehand, but the validator is trying to be 'smart' and pre-compute it. I've tried it and it seems to work well (in chrome) |
Will require further testing and unit tests, but this fixed it for me: |
This appears to be solved in the latest angular 1.2.3 |
Problem still occurring in v1.2.7. The documentation may indicate that it's expecting a string, but it does go against expectation as this complicates things if you want all properties to be databound and not something mid-term. |
I can't repro this with 1.2.7: http://plnkr.co/edit/4HU4jdG1ljrnoXYuegQo?p=preview it appears to work correctly. can you please post expected vs actual result and any other instructions needed to repro the bug. |
Hi Igor, Thanks for having a look at this! An adapted version of yours generated (works):
My generated HTML (doesn't work):
Resulting in:
I can't reproduce my problem in the Plunkr, so I'm at a loss. |
We are having this issue with 1.2.13 Steps:
So the {{max}} interpolation is not re-validating the input, but changing the input causes re-validation including the new value. This is the bug we are experiencing with 1.2.13 EDIT: |
Caitlin; On Wed, Feb 19, 2014 at 11:03 AM, Caitlin Potter
|
The issue appears on this case http://plnkr.co/edit/4CPpJl when min and max value are dynamically set. |
I think the solution to this is the |
I am currently having a related issue. In my case, when the numberInputType controller is instantiated, Unfortunately my employer thus far has not approved (and looks like it won't any time soon) the CLA so someone else will have to make this PR. PS: also needs a check for NaN since attr.max could be anything during validation now. |
Still present in 1.2.18 |
@gkocjan can you provide an example? this seems to have been fixed back in 1.1.3, based on a quick bisect of releases --- http://plnkr.co/edit/7KNcOK7CVSjWDUt9JHbN?p=preview (works in 1.1.3, fails in 1.1.2), probably was originally fixed by bb8448c (It's also working in @petebacondarwin we could probably close this issue if this was fixed by that CL |
@caitp here is example: http://plnkr.co/edit/vLq79q4tZJn4PHDbN73i?p=preview In second example after adding variable in controller it also starts to work. Just uncomment |
@gkocjan http://plnkr.co/edit/Vy6OYQH18FcjqEnOoVT9?p=preview (setting the page to page 10 will invalidate the model) (Also, the pagination directive doesn't use |
I can confirm this. If I set |
if you can reproduce that, you need to show your issue, because as far as anyone can tell this is working. Can you make a demo, @lhahne? |
This was a concurrency issue at least for me. If max is null in the beginning and later gets updated, the browser will pick this up but angular will not. |
This means an actual reproduction using a recent release or snapshot build, so that we can determine if this is a bug to be fixed. |
Here you go http://plnkr.co/edit/EuuRHb9vUVw4ODhmsfjq?p=preview The first checkbox checks for max, the second does not. Not sure if this is actually even supposed to work in this case. |
@lhahne I see, that's a fairly trivial fix. The issue is the way we're testing if we need to register a min/max validator or not: https://github.com/angular/angular.js/blob/master/src/ng/directive/input.js#L1083 if(attr.max) { This evaluates to the empty string because the property is not set in scope yet, though the attribute is provided. This is trivial to fix if you'd like to submit a pull request. If not I'll patch that later today |
@caitp I think you even had a pull request with that fix back when max/min was still on $parsers: #6002 Here's an issue that would be closed by this fix: #6369 (comment) |
nah, that PR was for a different issue, but this one is similarly trivial |
I was trying to fix this but I can't seem to get this to fail in unit tests. This is what I tried and I do not understand why it does not fail even though it is completely analogous to my previous example of the problem.
|
Looking at the number validator, there are two problems here: Theoretically, the number validations should be added to the $validators collection, but since number also uses formatters, and there is currently some discussion about the whole inout processing, it's probably best to defer this. @lhahne Your test doesn't work, because when max is undefined or null before compilation, no max validator is set. When you change max afterwards, it doesn't fail because the max validator is not set, and even if it was, it would still fail because the directive doesn't listen to max={{value}} changes. |
👍 |
This is still unfixed right? Or does Angular by design only handle the Here's a simple example of the bug in Angular 1.2.22: http://plnkr.co/edit/lNemYyFrHF9gyRgY8KIT?p=preview |
Same problem with input type='date' min max for 1.3.0-beta.19. |
@matsko is this something we can address in RCs? |
I have a PR that fixes this for date. The same logic applies here. And no it won't cause any breaking changes so we're safe to patch during RC. |
As of this fix if the max or min value is changed via scope or by another ngModel then it will trigger the model containing the min/max attributes to revalidate itself. Closes angular#2404
This is working on the current master, but if the min or max value is changed then the input field doesn't reconsider itself. This PR fixes the issue for |
…nge for number inputs As of this fix if the max or min value is changed via scope or by another ngModel then it will trigger the model containing the min/max attributes to revalidate itself. Closes angular#2404
…nge for number inputs As of this fix if the max or min value is changed via scope or by another ngModel then it will trigger the model containing the min/max attributes to revalidate itself. Closes angular#2404
Still experiencing this issue on v1.3.10... http://plnkr.co/edit/uS4zsh05jeP7pF7A2aVk Using an initialisation value that isn't |
@adrianduke try ng-max='{{max}}' |
It would have expected this commit to fix it - b350283 |
Ah! Fixed here: abfce53 |
@petebacondarwin WIll it be released in upcoming 1.3.16 release? |
@piotrkulpinski - this was already there in 1.3.14 and so will continue to appear in the next release too. |
+1 here 1.4.x |
Hi guys, in the documentation is missing the attr ng-max and ng-min for input type number. |
Interesting! They are not documented as standalone directives either... |
just use ng-min and ng-max |
For for old Angular versions use fallback values before model is initialized: |
When using an input of type number, with the max (or min) attribute set from the model, then the max field is not set in the error object of the input. This is due to the fact that in method "numberInputType", the value of attr.max is undefined. It is (probably) set from the model only later.
Checking the HTML, shows that the max attribute gets the correct value, set from the model.
In summary, the following does not work as expected:
input type="number" max="{{max}}"
The $error for this input field does not contain a boolean value named "max".
Here is a demo : http://plnkr.co/edit/YiExG5GpFt5MKKXoO4GE
The text was updated successfully, but these errors were encountered: