Bug fix: Prevent event propagation on invalid key presses

[nicolasgasco]

Hello! I noticed a behaviour that looks a bit weird to me and led to a bug ticket in Production (here for Qonto employees).

When @numberOfDecimal is set to 0 (so @value should always be an integer), following filtering logic is used for e, ,, and . key presses:

// ember-amount-input/src/components/amount-input.js
  @action
  onKeyDown(event) {
    if (event.keyCode === KEY_CODE_E) {
      return false;
    } else if (
      this.numberOfDecimal === 0 &&
      [KEY_CODE_FULLSTOP, KEY_CODE_COMMA].includes(event.keyCode)
    ) {
      return false;
    }
  }

But, since the events are not prevented from bubbling, you can actually type those characters in the input. The value is then converted to an integer on focus out. This leads to some weird states because inputs like 10.5 are actually NaN, while 10,5 would be correctly rounded to 10.

You can see here how the input behaves before and after preventing events from bubbling.
With propagation:

TestApp.Tests.-.13.July.2023.mp4

Without propagation:

TestApp.Tests.-.13.July.2023.1.mp4

I think preventing the event from propagating would make the component behave in a more rational way: if the input value is an integer, you shouldn't even be allowed to type e or a comma in the same way you can't type a letter or any other symbol.

Note on testing: I tried modifying the existing tests, but it seems that typeIn testing helper doesn't actually work like manually typing, so I don't think there's really a way to test this behaviour. The changes added in the PR don't make e, . and , key should be masked when numberOfDecimal={{0}} test fail.

[vscav]

Hi @nicolasgasco! I followed the discussion you had with Marcin - did you try this solution on multiple browsers? Other than that, LGTM 👍

[nicolasgasco]

Hi @nicolasgasco! I followed the discussion you had with Marcin - did you try this solution on multiple browsers? Other than that, LGTM 👍

As far as the scope of this PR is concerned, behaviour is consistent in Chrome, Firefox, and Safari: e, ,, and . presses are ignored.

The only inconsistent behaviour is that Firefox and Safari actually allow all kind of key presses, so you could input a letter for example. But this is already the case.