Fix crash with CJK keyboard with emoji at end of text field

[moffatman]

The isRTLAtPosition method had a bug, it used NSInteger max = [_selectionRects count] instead of NSInteger max = [_selectionRects count] - 1. But I realized we don't even need the function any more, it was used in a few places in previous iterations of #36643, but in the only place remaining, we actually already have the selection rect and don't need to search for it by position.

Btw as an explanation of the crash, I guess there is some mismatch between code point and character count somewhere. UIKit was asking for caretRectForPosition:2 when we only had 1 character. This could have only crashed when floating cursor selection was used, but actually when switching to CJK keyboard, UIKit turns out to use caretRectForPosition to calculate something about the composing rect.

Fixes flutter/flutter#128031

Pre-launch Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• I read and followed the [Flutter Style Guide] and the [C++, Objective-C, Java style guides].
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See [testing the engine] for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the [CLA].
• All existing and new tests are passing.

[LongCatIsLooong]

The old implementation doesn't seem to have this check?

[LongCatIsLooong]

Also you might have to special case it when characterAfterCaret is a newline character, iirc SkParagraph reports it as an empty textbox at the end of the current line (instead of at the beginning of the next line).

[moffatman]

Here we use selectionRectsForRange instead of directly looking at the array. I put a check, because I guess if someone subclasses and reimplemented selectionRectsForRange, this would crash if it didn't return specifically FlutterTextSelectionRect. Not sure if this is really a concern...

Not sure what you mean about the special case. But for end-of-line, it does work correctly because I have added affinity into the FlutterTextPosition. So it will go to the characterBeforeCaret section.

[LongCatIsLooong]

If the document is "{newline}A" (so 2 characters), placing the cursor at (1, upstream) should point to the start of the second line. I think it would fall into the "remaining cases" category (around line 1718) and returns

    return CGRectMake(characterBeforeCaret.origin.x + characterBeforeCaret.size.width,
                      characterBeforeCaret.origin.y, 0, characterBeforeCaret.size.height);

which is going to be the right edge of the zero-width TextBox skparagraph returns for the newline character at the first line.

[moffatman]

As I understand upstream/downstream, it only comes into play where you have word wrap breaking lines. When you have a hard line-break, we have distinct indices at the end of line 1 and the beginning of line 2. And so most of the time the affinity is downstream, exccept at the end of a word-wrapped line.

I tried out the "\nA" scenario and it seems to work as expected in all 3 possible cursor locations. In the specific one you highlighted (cursor at index 1), it used the middle branch (rects.count == 2 && affinity == UITextStorageDirectionForward). I think this isn't a concern as you will never actually get that affinity (1, upstream) using either keyboard or touch?

[LongCatIsLooong]

you will never actually get that affinity (1, upstream) using either keyboard or touch?

Ah that's probably true.

But I think newlines are still special (sorry my example was bad). I tried getting the text boxes for "A\n":

    final TextPainter painter = TextPainter(
      textDirection: TextDirection.ltr,
      text: const TextSpan(text: 'A\n'),
    )..layout();
    for (int i = 0; i < 2; i++) {
      print(painter.getBoxesForSelection(TextSelection(baseOffset: i, extentOffset: i + 1)));
    }

the output:

[TextBox.fromLTRBD(0.0, 0.0, 14.0, 14.0, TextDirection.ltr)]
[TextBox.fromLTRBD(14.0, 0.0, 14.0, 14.0, TextDirection.ltr)]

when index == 1 and the affinity is UITextStorageDirectionForward this should place the cursor at the start of the second line. But if you look at the output both TextBoxes are on the first line.

[moffatman]

Ah I get it now. But I don't know if we can fix that here, if we don't even have any text box on the second line, we can't even make a guess of the correct position? It needs to be fixed upstream in skparagraph. And there isn't any regression in this PR. I hope we can ignore this, and merge it to avoid the hard crash.

[LongCatIsLooong]

SGTM. Probably not a SkParagraph issue I think, we should probably add a bit more information to rects the framework sends.

[LongCatIsLooong]

I think we only send the rects for visible characters in a multiline text field, so technically this also includes the case when the selection reaches the end of the visible text? Would this prevent the user from scrolling the text field using force touch?

[moffatman]

This API is used by UIKit to figure out where to initially position its internal tracking of the selection gesture. So it would only be called on visible characters. And the logic still holds even if there are characters after current position that don't have a rect. As long as we have the 1 visible character before the cursor.
And yeah, to implement full scrolling we would need to send rects for all characters. A matter for another PR in framework.

[hellohuanlin]

I think we can assert the class type here?

[moffatman]

Not sure what you mean. I am checking the class type?

[hellohuanlin]

Something like:

FlutterTextSelectionRect *rect = (FlutterTextSelectionRect *)rects[0];
if (rect...)

Because the rect must be the correct type right? There is no way isKindOfClass returns false, am I right?

[moffatman]

Technically it's possible, this method signature is not FlutterTextSelectionRect*, but UITextSelectionRect*.