Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

Broken ngStep for input[type="number"] directive #15504

Closed
lucassus opened this issue Dec 13, 2016 · 3 comments
Closed

Broken ngStep for input[type="number"] directive #15504

lucassus opened this issue Dec 13, 2016 · 3 comments

Comments

@lucassus
Copy link

Do you want to request a feature or report a bug?

It's a bug

What is the current behavior?

For values like 1.16, 20.1 etc the input[type=number] field with ng-step="0.01" is marked as invalid.

Steps to reproduce:

  1. Update to AngularJS version 1.6.0
  2. Define an input[type=number] with ng-step="0.01"
  3. For values like 1.16, 20.1 the field will be marked as $invalid

See a small demo: https://plnkr.co/edit/LW2BsaA7FfEVu9nB6RoG?p=preview

I believe it's a problem with floating points arithmetic and this little method https://github.com/angular/angular.js/blob/master/src/ng/directive/input.js#L1563

    // ...

    value = value * multiplier;
    stepBase = stepBase * multiplier;
    step = step * multiplier;
  }

  return (value - stepBase) % step === 0;

When for instance value = 1.16 and multiplier = 100 value * multiplier gives us 115.99999999999999 so the return expression returns false even when the given value is valid.

@gkalpak
Copy link
Member

gkalpak commented Dec 13, 2016

BTW, this also affects ngStep on input[range] (since both input types share their step implementation).

gkalpak added a commit to gkalpak/angular.js that referenced this issue Dec 13, 2016
Previously, the validation would incorrectly fail in certain cases, due to
Floating Point Arithmetic limitations. The previous fix for FPA limitations
(081d06f) tried to solve the issue by converting the numbers to integers,
before doing the actual calculation, but it failed to acount for cases where the
conversion returned non-integer (again due to FPA limitations).
This commit fixes it by ensuring that the values used in the final calculation
are always integers.

Fixes angular#15504
gkalpak added a commit to gkalpak/angular.js that referenced this issue Dec 13, 2016
Previously, the validation would incorrectly fail in certain cases (e.g.
`step: 0.01`, `value: 1.16 or 20.1`), due to Floating Point Arithmetic
limitations. The previous fix for FPA limitations (081d06f) tried to solve the
issue by converting the numbers to integers, before doing the actual
calculation, but it failed to account for cases where the conversion itself
returned non-integer values (again due to FPA limitations).
This commit fixes it by ensuring that the values used in the final calculation
are always integers.

Fixes angular#15504
@gkalpak gkalpak modified the milestones: 1.5.10, 1.5.11 Dec 15, 2016
@benneq
Copy link

benneq commented Dec 23, 2016

this should also be added to 1.6.0 (or is it just not included in 1.6.1 changelog? see: https://github.com/angular/angular.js/blob/master/CHANGELOG.md )

@gkalpak
Copy link
Member

gkalpak commented Dec 24, 2016

This has not been fixed yet. Once it is fixed, it will be included in 1.5.x and 1.6.x.

gkalpak added a commit that referenced this issue Dec 29, 2016
Previously, the validation would incorrectly fail in certain cases (e.g.
`step: 0.01`, `value: 1.16 or 20.1`), due to Floating Point Arithmetic
limitations. The previous fix for FPA limitations (081d06f) tried to solve the
issue by converting the numbers to integers, before doing the actual
calculation, but it failed to account for cases where the conversion itself
returned non-integer values (again due to FPA limitations).
This commit fixes it by ensuring that the values used in the final calculation
are always integers.

Fixes #15504

Closes #15506
ellimist pushed a commit to ellimist/angular.js that referenced this issue Mar 15, 2017
Previously, the validation would incorrectly fail in certain cases (e.g.
`step: 0.01`, `value: 1.16 or 20.1`), due to Floating Point Arithmetic
limitations. The previous fix for FPA limitations (081d06f) tried to solve the
issue by converting the numbers to integers, before doing the actual
calculation, but it failed to account for cases where the conversion itself
returned non-integer values (again due to FPA limitations).
This commit fixes it by ensuring that the values used in the final calculation
are always integers.

Fixes angular#15504

Closes angular#15506
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants