paper-input type="number" floating doesn't work if you don't start with a number

Description

if you have paper-input type="number" and auto-validate pattern="[0-9]+" and you start typing with a '-' or an 'e' (allowed characters beside numbers), the floating does not work.

Expected outcome

The label is floating. Like this:

Actual outcome

Label not floating. Like this:

One minus works:

Two not:

I know that this entry makes no sense, but nevertheless it should float. Or should it only float if the entry is valid?

Live Demo

Steps to reproduce

paper-input
type="number"
auto-validate
pattern="[0-9]+"
start typing with e or -- or another allowed non number

Browsers Affected

Unfortunately this is a can't fix. The native input with type="number" doesn't send an event when you type the incorrect characters, and they're not saved in the input itself, so there's no way to detect that this text change happened and force the label to float.

(duplicate of #377, which has more details)

@notwaldorf can't we use the validity property of the input?
we have validity.badInput set to true when this happens!
see also: https://developer.mozilla.org/en-US/docs/Web/API/ValidityState

I think we could listen to keypress, and look if badInput is true, and then float also!

The actual validity of the input doesn't really have anything to do with it, since you don't get an event when the validity changes, so you need to listen to keypresses anyway. And that actually much more complicated than it sounds:

keypress is fired before the value is set, so after the first character is typed, the value will still be ""; you could inspect the char code, but you'll have to add custom logic for it (like, you'll get a keypress event for typing d, but even though the value is empty, you don't see anything on screen. you will also get a keypress for typing e, where the value will also be empty, but you will see something on screen.
escape doesn't fire a keypress, but does fire a keydown, which gives you a bunch more events you don't actually need (but since you need to unfloat the label, you might need to check this out too)
this code/listener needs to run for any kind of input, even though it's only needed for type="number", because you can't observe when the type changes very easily.
also, from the last time i had to touch keypress code it was actually a mess, because every browser implements this differently.

I'm leaning towards not fixing this since the solution sounds super messy and hard to maintain (and expensive, that even will fire every time you type), and the bug it fixes is actually fairly small, and you could technically write this workaround (the keypress code) in your code.

If I add this code:

$0.onkeyup = (e) => console.log(e.path[0].validity.badInput)

to the input in your paper input example: https://www.webcomponents.org/element/PolymerElements/paper-input/demo/demo/index.html (the one with the $ in front) it works as expected
I got "true" in the console when the value is bad

when you look here:

paper-input/paper-input-container.html

Line 591 in 43ad083

    
           if (value || value === 0 || (inputElement.type === 'number' && !inputElement.checkValidity())) {

you already have the check for validity, I think only the trigger is missing

@notwaldorf if I work on a fix wich listens for keyup, will this be accepted?

Is there also a bug in the element, cause the event listeners in the attached callback are added every time the control is attached to the dom. I use dockspawn (a docking framework), wich dettaches and attaches elements when you move your dock pages

It works, if a add this to the ready:

this._inputElement.children[0].addEventListener("keyup", (e) => this._handleValue(this._inputElement));

and change:

  if (value || value === 0 || (inputElement.type === 'number' && !inputElement.checkValidity())) {

to

  if (value || value === 0 || (inputElement.children[0].type === 'number' && !inputElement.children[0].checkValidity())) {

i know this fix is not correct, but i don't know how the correct fix should look like? shoul iron-input wrap checkValidity?

@notwaldorf have you read my comments? Do you still think itˋs not worth to be fixed?

I have read, but can you send a PR so we can actually run tests and I can see the diff? It's starting to be hard to keep track of what the change exactly is, without the full diff :)

I will do a pull req.

But I'm not sure, if I only should fix it if child is a input, or also look if child is a iron-input. If it's a iron input, iron input has to expose some of the inputs api!

I've created a fix, seehttps://github.com//pull/642 but googlebot says I've not signed the cla (but I have)

fixed it, committed with wrong GH username ;-(