Repository navigation
TextSelection doesn't support TextAffinities for non-collapsed selection #88135
Description
TextSelection has a single affinity property, and according to its docs, it only applies when collapsed:
If the text range is collapsed and has more than one visual location (e.g., occurs at a line break), which of the two locations to use when painting the caret.
I think that this may be an oversight and a source of bugs, especially when using a keyboard. For example, these selections are different, but Flutter has no way to distinguish between the two:
| extent TextAffinity.downstream | extent TextAffinity.upstream | Flutter treats them both as: |
|---|---|---|
This text wra|ps because it's |too long. |
This text wra|ps because it's | too long. |
 |
Why does it matter?
When using keyboard shortcuts that jump to the beginning/end of a line, it's important to know what line the base and extent are on. Consider doing cmd-shift-right (expand to end of line) in my example in the table above. If the extent is upstream, the selection shouldn't change. If it's downstream, it should select to the end fo the field. Always assuming one or the other affinity won't always make sense.
Related
https://github.com/flutter/flutter/pull/87973/files#r685632915
#85653
Activity
LongCatIsLooong commentedon Aug 26, 2021
I think whether we need separate text affinities for each end point depends on the visual appearance of the selection/caret.
On desktop platforms a non-collapsed selection generally doesn't have a "handle" so it doesn't need text affinity to disambiguate the different visual locations of each endpoint with the same logical position. From what I'm seeing on macOS, non-collapsed selections do not have cursor affinity there, since a non-collapsed text selection on macOS is visually represented by a few highlighted rectangles. Having
TextAffinity.upstreamfor soft line breaks in this case would just mean an empty rectangle being placed at the end of the previous line, which does make any difference visually.And in some text editors the caret is visually the same as a single character selection. In that case there's no ambiguity when the caret is placed around a soft linebreak or a bidi boundary.
I don't have a tablet with me that has both selection handles and hardware keyboard support. I wonder if iPad supports the same selection shortcuts as macOS, if it does then we'll probably have to add text affinity for both end points.
justinmc commentedon Sep 13, 2021
I also don't have an iPad unfortunately, but we should check that at some point.
I agree with you about Mac not needing affinity for non-collapsed selections after playing around with it. I even tried some tricky stuff like selecting from the start of one line to the previous line, then trying to cmd-shift-right to jump to the end of the line. It doesn't do anything, because it seems that Mac is assuming that the base is upstream.
Maybe we can also make some explicit and documented assumptions about the affinity of the base/extent when not collapsed.