Phoenix_live_view: input type="number" erase bug in Chrome

Created on 8 Aug 2019  Â·  5Comments  Â·  Source: phoenixframework/phoenix_live_view

Environment

  • Elixir version (elixir -v): 1.9.1
  • Phoenix version (mix deps): 1.4.8
  • NodeJS version (node -v): 12.7.0
  • NPM version (npm -v): 6.10.0
  • Operating system: Ubuntu 19.04
  • Browser: Chromium: Version 76.0.3809.87 (64-bit)

Actual behavior

I've created a fork of the phoenix_live_view_example repo to show this problem. You can clone the repo, follow the setup instructions to run it and go to http://localhost:4000/users/new on a Chrome browser.

  1. Type "10.00" in the "Test" input field.
  2. Erase the last 2 decimal digits.

As soon as you reach the dot, the cursor will jump to the beginning and the value will change to "10".

ezgif com-video-to-gif

This issue only happens on Chrome, I've tried it both on a Mac and Ubuntu.
Firefox doesn't have this issue.
Note I don't have any browser plugins installed on Chrome.

Expected behavior

When erasing and reaching the dot, the cursor should not jump and the value should remain "10."

Most helpful comment

@LightningK0ala I have a PR up for ya! Let me know what you think and see if you can test it out.

https://github.com/phoenixframework/phoenix_live_view/pull/299

All 5 comments

I've been investigating this. This is an issue with how Chrome parses invalid floating point numbers. In the case of when you get to 10., Chrome says, input.value is "" and we update accordingly. Firefox reports 10. on input.value however

I've been pondering a fix, so let me see if we can handle gracefully.

@LightningK0ala I have a PR up for ya! Let me know what you think and see if you can test it out.

https://github.com/phoenixframework/phoenix_live_view/pull/299

@snewcomer Thanks for the PR! Unfortunately it didn't fix it for me. I spent quite some time debugging the issue today and I think I found a fix #300.

@LightningK0ala I've made a third approach here. I'm think between all three approaches, we have a solution somewhere 😉. Let me know what you think. I sort of took both of our approaches. Effectively, for number inputs, we should not morph if badInput or is the current active element. This is what React has done in the past as well. The upside is users can still hook into server sent events, but we just decide not to morph number inputs.

@snewcomer Sorry for the delay in responding.

I've reviewed the PR and tested it. It's working well now I think you hit on the right solution, thanks for taking this on!

Was this page helpful?
0 / 5 - 0 ratings