Improving navigation in text box widgets with existing selection

[Enyium]

At least on Windows 10, when having a selection in a text box in other software and pressing Left/Right (or for one-line text boxes also Up/Down), the selection is replaced by a zero-width selection with the cursor position at the side of the selection that corresponds to the pressed arrow key. But Slint currently takes the cursor position from the selection, which is either to the left or right of it, and (1) makes the selection zero-width, and (2) derives the new cursor position from the selection-associated one, as if it was zero-width to begin with.

To visualize, Slint's current incorrect behavior is (lines representing chronological order of one-line text box states with | as the cursor, capital letters meaning selection):

abcDEF|ghi
[pressing Left]
abcde|fghi

abcDEF|ghi
[pressing Right]
abcdefg|hi

(similar, if cursor is to left of selection)

The correct behavior would be:

abcDEF|ghi
[pressing Left]
abc|defghi

abcDEF|ghi
[pressing Right]
abcdef|ghi

[tronical]

Thanks for the detailed report.

[ogoffart]

Should be fixed in this function: https://github.com/slint-ui/slint/blob/c2ebe3ca2a7f77ad4eb88960801dd28e33ef0d04/internal/core/items/text.rs#L1122 The code currently always use last_cursor_pos which is computed from the cursor pos as a base, but depending on the direction, it should either use the cursor position, or the anchor position.