RTL cursor and keyboard behavior prevents intuitive editing of the date value in Input Date Picker

[eriklharper]

Actual Behavior

In RTL mode, it is difficult to edit portions of the date value with the keyboard in Input Date Picker's input field because the cursor jumps around unexpectedly when editing the value or moving the cursor with the arrow keys. The left arrow key in certain places will move to the right (and the right arrow key moves to the left), such as within moving the cursor between groups of numbers, but in other cases moves the cursor in the same direction as indicated by the key, such as when moving the cursor on either side of the / separator between the date values.

The Backspace key also doesn't always work as expected. Sometimes hitting backspace will actually remove characters and sometimes it won't depending on the cursor position. Sometimes hitting the Delete key will remove a character when the Backspace key doesn't.

Originally posted about here:

          > I _think_ this is fixed now on the latest `1.4.1`. @Olga8614 would you be able to re-verify this with the latest calcite version? I forked Franco's codepen with the latest calcite and my keyboard edits are working after changing the value and pressing enter or blurring the input:

https://codepen.io/eriklharper/pen/wvYVvzE

The year can be edited from the keyboard - fixed
The day input from the keyboard still does not take effect - not fixed

Originally posted by @Olga8614 in #4569 (comment)

Expected Behavior

• The left arrow key should always move the cursor to the left, regardless of text direction
• The right arrow key should always move the cursor to the right, regardless of text direction
• The Backspace (and Delete) keys should always remove the character to the right of the cursor in RTL mode and always remove the character to the left in LTR mode.

Reproduction Sample

https://codepen.io/eriklharper/pen/wvYVvzE

Reproduction Steps

1. Click into the input with the mouse or tab into it to focus it with the keyboard
2. Hit the left and right arrow keys to move the cursor around
3. Notice that it jumps around unexpectedly and doesn't consistently go where you think it should go
4. Hit Backspace in different spots of the value
5. Notice that it doesn't always remove characters and doesn't always remove the characters you expect. It also will remove some characters that aren't adjacent to the cursor

Reproduction Version

1.4.0

Relevant Info

This seems to happen consistently on all browsers, but there could be slight variations in behavior across some.

Regression?

No

Priority impact

p2 - want for current milestone

Impact

No response

Esri team

ArcGIS Online

[eriklharper]

This article explains in detail why some of this behavior occurs in the browser: https://marijnhaverbeke.nl/blog/cursor-in-bidi-text.html

[jcfranco]

@annierm18 Could you confirm the expected behavior from the description is the desired approach? Genuinely curious because this is something I've noticed before in other UI libraries and thought it was by design due to the BiDi algorithm.

[eriklharper]

@annierm18 Could you confirm the expected behavior from the description is the desired approach? Genuinely curious because this is something I've noticed before in other UI libraries and thought it was by design due to the BiDi algorithm.

I got confirmation from Cecilia Sung in the Internationalization Services Teams Channel here:

[jcfranco]

@eriklharper Awesome, thanks for confirming. 🏆

[annierm18]

Yes, thanks @eriklharper! Let us know if you need any more info :)

[jcfranco]

Per today's check-in, closing as this won't be applicable once input masking is implemented (see #8624). We can revisit in the future based on user feedback.