Could you explain this change?

When textDirection: TextDirection.rtl is set for a TextField, pressing the down arrow key in the TextField triggers the following line first:

final List<ui.LineMetrics> newLineMetrics = _editable._textPainter.computeLineMetrics();

Let’s analyze this function:

List<ui.LineMetrics> computeLineMetrics() {
  ...
  return offset == Offset.zero
      ? rawMetrics
      : rawMetrics
          .map((ui.LineMetrics metrics) => _shiftLineMetrics(metrics, offset))
          .toList(growable: false);
}

When the TextField is in LTR mode, the condition offset == Offset.zero is true. However, when it is in RTL mode, the condition will not hold true (see the attached image).
As a result, rawMetrics is returned with modifications. The returned output is equivalent in value to rawMetrics.
Therefore, I replaced identical with listEquals, but I believe the correct solution is to fix the issue in the computeLineMetrics function itself.

That makes sense to me. The identical is incorrect for RTL.

I wonder if the _TextPainterLayoutCacheWithOffset.lineMetrics getter should do the shifting and then assign the shifted line metrics to its _cachedLinesMetrics. That's a risky change though, so it should probably be done in a separate PR.

I think that @MrMontazer you should continue with your current approach, but create an issue with this information. Point to your listEquals and say that should be changed to identical along with the refactor I described above, for performance reasons.

The current implementation of VerticalCaretMovementRun uses this hack to detect whether TextPainter recomputed its layout. So the use of identical here is intended.

IIRC the offset here has nothing to do with the writing direction of the text.

These changes are related to #139201.
I agree that this is incorrect. I think I will revert it to the previous state and leave fixing this issue for another pull request

Are we sure that this is the first place we can get the text direction from?

SelectionResult dispatchSelectionEventToChild(Selectable selectable, SelectionEvent event) {
  switch (event.type) {
    case SelectionEventType.startEdgeUpdate:
      didReceiveSelectionEventFor(selectable: selectable, forEnd: false);
      ensureChildUpdated(selectable);
    case SelectionEventType.endEdgeUpdate:
      didReceiveSelectionEventFor(selectable: selectable, forEnd: true);
      ensureChildUpdated(selectable);
    case SelectionEventType.clear:
      clearInternalSelectionStateForSelectable(selectable);
    case SelectionEventType.selectAll:
    case SelectionEventType.selectWord:
    case SelectionEventType.selectParagraph:
      break;
    case SelectionEventType.granularlyExtendSelection:
    case SelectionEventType.directionallyExtendSelection:
      didReceiveSelectionEventFor(selectable: selectable);
      ensureChildUpdated(selectable);
  }
  return super.dispatchSelectionEventToChild(selectable, event);
}

In selectable_region.dart line 2288, by detecting if selectable.widget.delegate is _SelectableTextContainerDelegate, we might be able to determine the TextDirection earlier.
However, it’s important to note that _SelectableTextContainerDelegate is defined in a different file.

So we don't know the text direction at this point because this is the whole SelectableRegionState, which internally could have different TextDirection widgets, such as with my example app (in #160516 (review)).

The idea that we have events that are not fully accurate until being updated like this seems kind of error-prone. I'm still thinking through what the better way might be though.

One possible solution could be to handle horizontal events directly in widgets that need to support them, such as Text, instead of translating right to forward. This would likely require significant changes.

The creator of the intent is likely going to have no information about who the receiving text field is going to be, so how does it know what text direction to use?

Actually, this field is assigned a value once the direction is specified. Check this.
However, I know that the way this behavior is implemented is not ideal, so your feedback could be helpful in improving the implementation of this issue.

this field is assigned a value once the direction is specified

I think that's a bit problematic as the widget that emits the intent may not know who the receiving text field is going to be (as a result it has not way to determine the current writing direction since different text fields can have different writing directions). IOW, when you're constructing the intent, there's no way to determine the correct TextDirection.

Also the intent should be (and it is) immutable.

nit: let's make it simpler. Maybe just whether the receiving text field should move the caret to the left / right by one character?

I should mention that there are many shortcuts for the TextField.
The simplest shortcuts are the left and right arrow keys.
However, combination keys that include the left or right arrow, such as Shift + Left Arrow, also exhibit reversed behavior in RTL (right-to-left) mode.
Do you still think the same way?

Sorry I wasn't clear, I meant maybe the documentation can be a bit simpler.