input_number almost impossible to use in box mode

[doudz]

Home Assistant release (hass --version): 0.55
Python release (python3 --version): 3.5.3
Component/platform: input_number
Description of problem:
input_number doesn't respect step if set to 0.5 in "box" mode. It works in slider mode

Expected:
input_number should use the specified step

[doudz]

Additionally on Chrome Android there is no up/down arrow so it's almost impossible to change a value.

[doudz]

Another things, since the value is constraint by min and max, it's impossible to type a value because the field is automatically correct to respect min or max
example : min = 15, max = 30
at start value is set to 15 (min)
I would like to set 19, so I press "del" to remove "5" but the field is set to "15" again before I can type the "9"

[githubbuh]

Home Assistant release ( hass --version ): 0.55
Python release ( python3 --version ): 3.5.3
Component/platform: input_number
Description of problem:

1. Unable to edit value by using backspace to remove and replace. backspace would not remove the value.
   Expected:
   hit end key, use backspace to remove value, then enter new value
2. Use of up/down arrow to adjust value creates an entry in the logbook for every press of the up/down arrows. starting value is 5, press up arrow for 6, press up arrow again for 7, press up arrow again for 8. Three logbook entries will be created showing change to 6, change to 7, and change to 8. haven't checked to see if three change events are fired.
   Expected:
   One entry in the logbook showing value changed from 5 to 8. Would expect to get just one event for value change from 5 to 8.

[NextNebula]

I made a pull request to add support for the step, min and max settings and to support decimal numbers.
home-assistant/frontend#451

[doudz]

The PR home-assistant/frontend#451 has been merged but the problem is still here in release 0.56.1
Now I can type 19,5 but using up/down arrow doesn't respect the step 0.5
And we still can type a value because the box auto set value to min or max during typing

Example :
min : 15
max : 30
step : 0.5
current value : 20
I want to type 19, so I click in the box to set the focus and I press backspace in order to delete 0 and 2 before typing 1 and 9 but when 0 is deleted the box is automatically set to 15 (min value)

The box should wait during typing, for example 500ms between the last keystroke and the auto correct.

[UMH-Home]

The box should wait during typing, for example 500ms between the last keystroke and the auto correct.
OR just wait for 'enter' for validation.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[mrchapp]

Still an (annoying) issue.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[yunnanpl]

Problem with input_number in box mode still exists.
Home Assistant version 0.79.1, installed a few days ago on Armbian on Cubieboard2.
Browser Chrome 69 (maybe there is some rendering problem on the browser side ?).

Issue: Input field not visible at all.
Expected: To see an input field to input data.

EDIT: On the other hand the input_text looks good and works well. I will try to have a look where is the difference with the html input tag so that it does not appear at all.

[doudz]

I agree, same problem with 0.79.3

[UMH-Home]

I think that the major factor is how the browser interprets the web page presented.
When I tried different browsers I got different results
What browsers are you using and can you try a different one to see what happens ?

[doudz]

Google Chrome 69 (Linux)
And same bug with Firefox 62 (Linux)

[yunnanpl]

The same on Chrome 69 (win), Edge 42 (win) and Safari 12.0 (iPhone).

[UMH-Home]

On a pc ? On Android ? On a mac ?
Can you access another browser ? On the same machine /different machine (what is the extent of the problem ?)
If it is a browser rendering problem, there's not a lot HA can do about it.
Having said that; Chrome is not a bit player in this market so should be supported to accurately render

[UMH-Home]

Hi All,
I've just got back to look at this in detail and I must apologise for assuming it was a browser issue.
I (once upon a time) had issues with getting at the spinner controls of the input_number, which was fixed so I assumed that this was a similar issue.
Having reviewed it on ALL the browsers I have access to on ALL the platforms I have access to, I find the symptoms identical and the box just completely inaccessible. Please see the attached photo.

I've reviewed the notes on the increment changes through from; about 79.0 (I'm not 100% sure when it stopped working) and can find no mention of changes to web content code/rendering.
But something has changed ... and NOT for the better.
Mutt

[yunnanpl]

Dear All,
I quickly checked the html code, and it seems that in the div with id=input_number_card, the paper-input tag is inside of the ha-slider tag. The ha-slider seems to be not important (maybe not necessary).
By pulling the paper-input tag one level higher, I could get the expected result (completely working, with scroll, not visible on the screenshot).

(even after removing the ha-slider tag, the functionality was fine, so it seems that this part is maybe not necessary).
The raw code seems to be more complex, so I would rather stay at the user side at the moment :)

[yunnanpl]

So... it seems that in the file app-084b7564.js there is this piece of html code on line 5319.
Interestingly the tag starts with but is closed with . I can believe that in the browser the code is being "cleaned" so the ha-slider seems to be closed in browser.
Unfortunately, this cleaning encloses the tag in the hidden tag.

So, if the word ha-slider will be exchanged with paper-slider in the line 5319, maybe it will work ?
I changed the line in my code, but I see no difference in the final output (in the browser).
Do I have to trigger recompilation somehow ? or remove some cached files like PYC or JS.MAP ?

EDIT: Tests done with success !
It is exactly the other way around, than what I thought.
When I correctly use the paper-slider tag, then both slider and input box is visible at once.
When I use the ha-slider tag, then everything works perfectly (both box and slider mode).

So in short, this line:
https://github.com/home-assistant/home-assistant-polymer/blob/34bfc1264708b9b60dbd47084b19f2d077dd95e9/src/state-summary/state-card-input_number.js#L44
has to be corrected and the tag exchanged with </paper-slider>.

[mariusebastian]

@yunnanpl what do you mean by "exchanged with < /paper-slider>"?
The line allready reads "< /paper-slider>".
Do you mean "[has to be ]changed to "?

You should probably add a pull request if this really fixes it.

If you are right then this PR from 2 weeks ago may have introduced the problem in the first place: home-assistant/frontend@3961eff#diff-ac832a113130c8082287f3037b457f02

What do you think @jeradM @balloob ?

[UMH-Home]

I think !!! it's fixed.
Well it appears to me to be so on 0.81.0
Let them know if anyone out there is still having problems with it.
Mutt

[doudz]

ok for me on 0.81.0, thanks !

[cgarwood]

Fixed in home-assistant/frontend#1861 which was part of 0.81. Please open a new issue if you still see issues 👍