feat(timepicker): activate type="number" for inputs

[fbasso]

fix #2334

input type as number is more appropriate for the timepicker, although the behavior is different depending on the browser:

• Chrome filter characters to only accept numbers,
• FF does not filter characters, but put a red border on blur if the value is not valid
• IE set the field empty on blur if the value is not valid
• Edge do nothing

The inner arrows have been removed by css, as the timepicker already provides

Even with these discrepancies, the big advantage is to get the numeric keypad on mobile. For this, the property "inputmode" is more appropriate (as we don't need the arrows), but it's not fully supported on mobile: https://caniuse.com/#feat=input-inputmode

In this PR, the tests on navigation had to be tweak a little, as it's not possible to use selectionStart and selectionEnd on inputs with type="number". I didn't find another way to change the type before testing the navigation.

[codecov-io]

Codecov Report

Merging #3236 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3236   +/-   ##
=======================================
  Coverage   92.04%   92.04%           
=======================================
  Files          91       91           
  Lines        3054     3054           
  Branches      505      505           
=======================================
  Hits         2811     2811           
  Misses        179      179           
  Partials       64       64

Flag	Coverage Δ
#e2e	62.99% <ø> (ø)	⬆️
#unit	89.47% <ø> (ø)	⬆️

Impacted Files	Coverage Δ
src/timepicker/timepicker.ts	98.8% <ø> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7a17683...7adfc64. Read the comment docs.

[fbasso]

However, there are lots of issues declared with type="number" declared on internet. This type seems to be not stable through browser implementations.

So I don't know if it's worth to take the risk to change it, just to get the numeric keypad on mobile.

[benouat]

I don't know what to do with this one...

It's true that for mobile device keyboard type pre-selection would be perfect !

But ...

the nasty side-effect is that it implies way too many non-working edge cases on the desktop. All browsers vendors have pretty much implemented input[type=number] differently in a non consistent way.

I would not go down this road....

---

What if we provide a directive input[ngbMobileNumberKeyboard] that hooks itself on the focus/focusin to dynamically swap the type just before the keyboard is opened, and change it back on next tick (only on mobile platform) ? Would it work to have the proper keyboard type ?

[benouat]

Let's close that one in favour of #3247.