Numeric Keypad not availiable when writing coordinate input in WGS84 DMS - format

[JohanPihelAtWork]

Description of the bug: When manually writing coordinate input for crosshairs (go-to-coordinate)-tool, numpad only works as input for other coordinate systems than WGS 84 DMS. All other tried systems (Sweref 99 TM 13 30, WGS 84, varaious other Sweref 99 TM variants, Pseudo mercator, Web Mercator) works as expected (both numpad och numbers row work as input), but WGS 84 DMS only accepts numerical input from the row of number keys above the alfabetical keyboard. Behavior when moving marker between numbers using arrow keys is also different in WGS 84 DMS than in other systems (in WGS84 DMS square blue full marking of present number instead of blinking pipe-line (|) after current number as in all other coordinate systems).

To reproduce: 1.Click crosshairs to activate location marker

2. klick the coordinate system to cycle trough to desirered coordinate system
3. Click the numbers box and move to the number you want to exchange with arrow keys
4. delete one number using delete
5. replace number using numpad (make sure you have NumLock engaged)

Expected behavior Consistent design of marking of current position in numbers box and consistent usability of numpad in all coordinate systems.

Screenshots Screenshots of different design of marker in Sweref 99 TM 13 30 and WGS84 DMS provided

Desktop (please complete the following information):

• OS: Windows and MacOS
• Browser All tested (Chrome, Firefox, Edge)
• Version Win 10, I Think High Sierra for MacOS

[JohanPihelAtWork]

I took a look at the code, and rows 245 - 260 in position.js (under controls) looks like they might be part of the observed behavior?

[huggla]

Check this site: https://www.toptal.com/developers/keycode

event.which and event.keyCode are deprecated in modern browsers. Use .key or .code instead.

[JohanPihelAtWork]

Additional potential troubles arise when the same key has different meaning depending if NumLock is active or not. The .code designation Numpad6 ( e.which = 33) is ArrowRight, but the same .code designation (NumPad6) is also e.which = 102 when NumLock is active. I think this might screw things up quite a lot..

[huggla]

Why not use event.key (in our case e.key)?

[JohanPihelAtWork]

hmm...good point. That one seems to be position agnostic as well, and in this case that is a good thing.

[steff-o]

OK, I confess. I overlooked the possibility of users using numeric keypad. e.key is the way to go. The rows 256 and 257 must be changed. And while at it remove all other usage of e.which.

Maybe I overworked it from the beginning, but I didn't want the users to be able to write anything that would not parse as it may not be obvious how to format the string. In non DMS coordsys it is possible to write any junk in the text box and get a parsing error on enter. I didn't change that when I made DMS as I didn't want to mess with something that no one had remarked on. That should probably also be fixed, but could quickly become messy if the coordinates could have different number of digits or the format is not known beforehand.

[JohanPihelAtWork]

No worries! I found that we are probably the only ones having a DMS-system available to our users, so I don't imagine that it is a big issue =) We have a preliminary plan to look at the issue on wednesday, hopefully we have good news after that :)

[steff-o]

Closed by merging #2036.