'0.*' not valid number value when trying to add value

[jagribble]

Prerequisites

• I have read the documentation;
• In the case of a bug report, I understand that providing a SSCCE example is tremendously useful to the maintainers.
• Ideally, I'm providing a sample JSFiddle or a shared playground link demonstrating the issue.

Description

When entering a float number such as `0.1' the number field isn't allowing the insertion of the '.'.

It works as expected with '3.14' for example but whenever the string starts with '0' the user input of '.' is not allowed to be entered.

The schema is confiured as below

 "fieldA": {
       "type": "number",
        "default": 1.0,
        "minimum": 0.0,
        "maximum": 1.0
   },

NOTE: You are able to enter the number as expected if you put a character infront of the 0 e.g '@0.1' and then deleting the '@'

Steps to Reproduce

1. Delete default value
2. Type in '0.'
3. Keep trying to enter the '.'

Expected behavior

The '.' should be allowed to be entered

Actual behavior

'.' character is not allowed to be entered after a '0'

Version

^1.2.1

I expect it is to do with the asNumber function (have commented on the line I think that is stopping it)

export function asNumber(value) {
  if (value === "") {
    return undefined;
  }
  if (/\.$/.test(value)) {
    // "3." can't really be considered a number even if it parses in js. The
    // user is most likely entering a float.
    return value;
  }
  if (/\.0$/.test(value)) { <<---- HERE does this also handle 0.07
    // we need to return this as a string here, to allow for input like 3.07
    return value;
  }
  const n = Number(value);
  const valid = typeof n === "number" && !Number.isNaN(n);

  if (/\.\d*0$/.test(value)) {
    // It's a number, that's cool - but we need it as a string so it doesn't screw
    // with the user when entering dollar amounts or other values (such as those with
    // specific precision or number of significant digits)
    return value;
  }

  return valid ? n : value;
}

[epicfaace]

Hmm, it's working fine for me at this playground link...

[jagribble]

Yeah so I have a playground locally and it works ok so I assume it’s to do with the configuration or how I have installed it for my project?

[abouchard97]

We are having the same issue as described by @jagribble. @epicfaace If you have a look at this updated playground link, you will be able to reproduce the issue.

The only change we've made was to add the

"fieldA": {
  "ui:options": {
  "inputType": "text"
  }
},

to the uiSchema.

If you then try to input 0.07 you'll be blocked at 0.
If you mess around and input 700 and then add 0. at the beginning to obtain 0.700, you'll be able to do so.

Definitely, either the number field regex or the asNumber method is in problem.

Also, as FYI, according to the documentation, it looks like the default html input is number and not text as expected (hence why we added the inputType property in the ui:options to reproduce the issue).

Fixing that issue would result in a breaking change so I don't know how it could be tackled in a community perspective.

@epicfaace I have time on my plate to fix this issue, let me know if you have any direction to help. We currently have a production issue around that one.

[epicfaace]

@abouchard97 found the issue -- see #1360. Meanwhile, for a quick production fix, you could just install from a particular commit:

npm i git+https://github.com/mozilla-services/react-jsonschema-form.git#3ad664d085c4d3b5f8c2599036b0e1d3a538f39a

If you have time, it would be great if you could add a test to finish up the pull request, as well as fix the other test it seems to have broken (although it doesn't seem to have changed functionality?) Additionally, I noticed another bug (which was there before that fix) in that when you type in a number starting with a "." on a text widget for a number type, it shows "0" instead. You could look into that as well; the fix might be in the same file I changed.

[abouchard97]

@epicfaace I've made a PR fix the broken test. I tried messing around with the number starting with . but it looks like a separate issue to me.

here (and following lines) : . is replaced by 0. and then the . is removed, and so the value is set to 0.