This needs a test of its own, but it's breaking a bunch of existing tests. I think this PR is fine but the tests can't handle calls to Selection.extendRight etc.

My workstation is offline and I'm having a hard time running these tests without it. I'll follow up once I get that powered on.

@GaryQian Any idea how I can fix these tests? The Selection.extend... and Selection.move... methods seem to do totally crazy stuff in tests, but not in an actual app. I think the code in this PR is correct, but the tests can't verify that it's correct.

I encountered the same problem in #15560 and worked around it, but I'm not seeing a way to work around it here. I tried all kinds of different ways to check that any telling method was called using mocks or spies, but I couldn't get anything that worked. Let me know if something jumps out at you.

Strange test behavior of the extend methods were also reported when working on #17393. I am not sure what is causing this.

There may be some value in looking at using the TextKeyListener as used in the above PR? This listener seems to perform many of the operations we are trying to do here and also multiplexes out to different sub-class listeners for handling of different keyboard types.

@GaryQian Actually I couldn't run tests even on a clean engine build without my PR. The problem was caused by extendLeft and extendRight because they were setting the cursor position at the most left or right position in test files. I don't know why but I guess not using actual layouts was causing the problem

Using extendRight and extendLeft is not a good idea because they have bugs with RTL as mentioned in #17393. @justinmc

I tried using TextKeyListener like in the PR by @alimahdiyar, but it seems it can't handle dpad events. onKeyDown just returns false for dpad events.

If it's not possible to use Selection's move/extends/Left/Right because it's buggy, then is there any other way to do this? Maybe manually detect grapheme clusters. I'm going to close this PR if no one has any other ideas.

Give me a day or two. I'm currently busy with fixing my system.
But I have some ideas for handling this.

Sounds good, thanks and let me know.

Implementation for DPAD movement is not in TextKeyListener subclasses and I think this is why you get false.
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/text/method/TextKeyListener.java#222
This one is the one I think should handle DPAD movement which is using extendLeft
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/text/method/ArrowKeyMovementMethod.java#69
I'm currently reading source code for handling last glyph and working on a clean PR.

I wrote a funciton to get left offset in #17960
However, I wasn't able to use it here.

if (selStart == selEnd && !event.isShiftPressed()) {
    int newSel = getOffsetBefore(selStart);
    setSelection(newSel, newSel);
}

this code snippet was setting the newSel correctly but setSelection was still setting the selection point to selStart - 1. I don't know why

Seems like I can't use things like Selection.extendLeft based on the conversation above, but getOffsetBefore would solve this problem for me. I'll keep my eye on #17960 and hope to use it here when it's merged.

Edit: I missed your point about it not working when you tried it, hmm. Anyway, I'll give it a shot if that PR moves forward.

The PR I was working on is merged. textUtils.getOffsetBefore is what we need here.

@alimahdiyar It seems to work! Sorry it took me awhile to get back to this. The left key is working as of e2c2e86 but now I've got to write something like getOffsetAfter for the right key.

I figured out that moving forward is handled differently in the android source code. I don't know whether text painting stuff can help in implementing getOffsetAfter here in flutter or not
https://android.googlesource.com/platform/frameworks/base/+/android10-c2f2-release/core/java/android/text/method/BaseKeyListener.java#306

I think it's not going to be possible to use Android's current approach for getOffsetAfter. The inner workings like getTextRunCursor were only added in API 29. I looked into reimplementing that, but ran into lots of private stuff that's not going to be easy to just copy over.

I'm going to try to implementing getOffsetAfter in a similar way to getOffsetBefore instead.

@GaryQian @alimahdiyar Ready for re-review.

I managed to port over getOffsetBefore to a new getOffsetAfter method. It appears to work with my manual testing and it passes the existing test cases, but I'm missing a lot of the context on these niche unicode characters. I mostly wrote this by basing it on the tests, so let me know if you see anything I've missed or any opportunities to clean up and deduplicate the code.

Hi, if the PR fails on Mac Web Engine, can you please rebase to the head? The reference in this file should be up to date: https://github.com/flutter/engine/blob/master/lib/web_ui/pubspec.yaml#L30

@nturgut Thanks for the heads up! It did fail, so I've updated to master.

@justinmc Yes, I was using physical keyboard for the emulator. But I added some logs there and it seems that function was triggered even on physical keyboard's keypress.

@alimahdiyar I tried adding log statements and using the physical keyboard arrow keys as well, and I also saw that the logs were called. However, the behavior appears different. It might be affected by some code in the framework, which I think I remember seeing at some point.

I'm going to merge this PR if it passes and plan to follow up in another PR if there are smaller bugs. Let me know if you see anything specific.

The Linux Fuchsia failure was re-run and passed here: https://ci.chromium.org/p/flutter/builders/try/Linux%20Fuchsia/11066