Fix: Fixed an issue where selection would get canceled after pressing upper arrow key

[RieBi]

Resolved / Related Issues

• Were these changes approved in an issue or discussion with the project maintainers? In order to prevent extra work, feature requests and changes to the codebase must be approved before the pull request will be reviewed. This prevents extra work for the contributors and maintainers.
  Closes Bug: Highlight and selection gets cancel if upper arrow key pressed afterwards #13798

Validation
How did you test these changes?

• Did you build the app and test your changes?
• Are there any other steps that were used to validate these changes?
  1. Open app
  2. Select an item
  3. Press F2 to rename
  4. Move pointer to middle of name
  5. Press Shift+UpArrow many times
  6. Confirm that selection does not get canceled
  7. Go to step 4
  8. Press Shift+DownArrow many times
  9. Confirm that selection does not get canceled

[RieBi]

So there were some inconsistent behaviors with how selection and up arrow key and down arrow key worked, for example pressing down arrow key moves pointer to the end, but if pointer was at the start, then it did nothing, which I suppose shouldn't have been the case.

I fixed those things along with the main issue where selection would get canceled after pressing shift+up arrow key multiple times. I hope my changes did not introduce any behaviors that were not meant to be

[yaira2]

@RieBi the original issue author reported that the issue is already fixed on their side so it might have just been a transient issue.

[RieBi]

@RieBi the original issue author reported that the issue is already fixed on their side so it might have just been a transient issue.

Well it's kind of interesting because the original issue that the author was talking about is still present in the latest release

[RieBi]

@yaira2 maybe I could open my own issue addressing the problem? Because the bug still exists in the latest release and it would have been nice to have it fixed

[RieBi]

OK I updated the branch to the latest commit of main. Regarding the logic, I don't think anything can be shortened there without breaking anything else (that's concerning @yaira2 's last review)

[yaira2]

@RieBi can you take a look at the commit I pushed?

[RieBi]

@RieBi can you take a look at the commit I pushed?

Yeah. I tested it, and it doesn't work quite as expected. It fixes like 50% of stuff, but the other 50% is still bugged and inconsistent.

Basically it's the same thing that I did first when I was fixing this issue, and it fixes some things, but there is more to it because the base textbox selection behavior is very buggy and weird per se.

[yaira2]

What types of issue are still present?

[RieBi]

For example, I suppose that intended behavior of pressing down arrow should move the cursor to the end. And it does, except when the cursor is at the very beginning - in that case it does nothing.

Also, shift+down arrow should expand the selection until the end, and sometimes it does, but sometimes not - specifically, when there's already any selection present.

So as I see it is repeatedly pressing up and down arrows should change the cursor position between beginning and end. But in reality, you can now go to start with up button, you wouldn't be able to go to the end by pressing down arrow, although pressing down arrow in other scenarios would bring the cursor to the end.

So I find it kind of frustrating to work with selection using keyboard as of now due to the mentioned issues.

[yaira2]

For example, I suppose that intended behavior of pressing down arrow should move the cursor to the end. And it does, except when the cursor is at the very beginning - in that case it does nothing.
Also, shift+down arrow should expand the selection until the end, and sometimes it does, but sometimes not - specifically, when there's already any selection present.

These appear to be the default behaviors for the WinUI text box, we can make adjustments if that's what users expect, but I think this needs additional feedback before we make any changes.