Repository navigation
Conversation
A number input sanitises its value before the app can read it, so a grouped entry is rewritten and the intended value cannot be recovered in JavaScript. In German Chrome, typing 12.000 steps stored 12 and typing 1.234,5 stored 1.2345 -- both silently off by a factor of 1000. Use a text input with inputMode so parseLocaleNumber receives what the user typed, and strip group separators there before canonicalising the decimal separator. The numeric range was already enforced by isValidNumericValue on submit, so the number input's min/max attributes were redundant. An entry carrying no digits now returns NaN rather than 0, so it is rejected instead of being stored as a zero measurement. Signed-off-by: minhal128 <rizvi4600779@cloud.neduet.edu.pk>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #320
Problem
A grouped numeric entry in the PWA is stored 1000x too small in German locale, silently. Typing
12.000steps stores12; typing1.234,5stores1.2345.<input type="number">sanitises its value before the app reads it, so the grouped text is already rewritten by the timeparseLocaleNumber()runs -- the intended value cannot be recovered in JavaScript.parseLocaleNumber()also never stripped the group separator.Change
numericInput()builds a text input withinputMode, soparseLocaleNumber()receives exactly what the user typed. The numeric keypad on touch devices is unchanged (inputModealready set it).parseLocaleNumber()removes group separators before canonicalising the decimal separator, and samplesformatToParts(11111.1)so agrouppart exists. Whitespace is dropped because several locales group with a no-break space a keyboard does not produce.NaNinstead of0, so it is rejected rather than stored as a zero measurement.Why min/max were removed
min/maxare inert on a text input, andisValidNumericValue()already enforces the same range on submit, plusNumber.isIntegerfor counters. Keeping the attributes would have been dead code. No caller readvalueAsNumber,stepUp, orstepDown.Verification
End-to-end in real Chrome per locale, typing with keystrokes and passing
input.valuethrough the realparseLocaleNumber():12.0001.234,52140,512,0001,234.52140.5npm run typecheck)npm run lint)npm run build)git diff --check: PASSNot run: PHP CS, Psalm, PHP unit tests, OpenAPI generation -- no PHP or API surface is touched by this change and I have no Nextcloud container here. Stylelint reports 13 pre-existing
rule-empty-line-beforeerrors inStatisticsChart.vue/StatisticsMeasurements.vue, untouched by this PR.