You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
If you type some text and then a complex emoji, the caret will stay at the start of the emoji rather than move to the end.
This resembles #50563, #98516, and #118403, but the symptoms are subtly different, and the fix is unrelated although it's in a nearby part of the code. (I'll be sending a PR with both fixes soon.)
Steps to Reproduce
Go to any ordinary text input field in a Flutter app, such as the code sample below. Use a device where you can easily input emoji.
Type the letters "abc", then a complex emoji like "👩🚀". (A simple emoji like "👍" won't show the issue; details below.)
Type some more text.
The cursor (aka caret) moves to the end of each character you type.
All the text you type is shown in the order you typed it.
On typing the emoji, the cursor stays at the start of the emoji.
On typing more text, the cursor jumps back to the end. All the text you type is correctly shown in the order you typed it. So this shows that the underlying text input state knows the cursor should be at the end, and we're just painting it in the wrong place.
In order to trigger the issue, the emoji's length in UTF-16 code units has to not be a power of 2: it has to be something other than 1, 2, 4, 8, etc. The simplest emoji are 1 or 2 code units long and don't trigger the issue. Most emoji that have a gender or skin-color modifier, or show a family or make other use of the zero-width joiner code point, do trigger the issue.
The repro may depend on the fonts you have on the device. I observe it on a Pixel 5 running Android 13, and on an iPhone 7 running iOS 15.
If you type "a👩🚀" or "ab👩🚀" instead of "abc👩🚀", then when you type the emoji, the behavior is still wrong but with a different symptom: the cursor will jump backward to the beginning, instead of staying at the start of the emoji. This symptom is caused by #50563.
It turns out that `Paragraph.getBoxesForRange` will not accept a
negative index for the start of the range; if you pass one, it
will return an empty list. We'd been doing that in
`TextPainter._getRectFromUpstream`; this was causing flutter#50563, flutter#98516,
and flutter#118403. (Arguably this makes them duplicates of each other,
but they looked quite distinct until being debugged: they involve
complex emoji, zalgo text, and Indic script respectively.)
Fix that by clamping the start to zero, because what we really
intended here in that case is the whole text up to the given
Then it turns out that we were sometimes reaching this line with a
negative end index too (when the selection is empty on reaching
`RenderEditable._updateSelectionExtentsVisibility`.) That was
giving an empty list of boxes, but if we clamp the start but not
the end, we'd get back boxes for the whole text instead. Avoid that
by short-circuiting that case at the top of the function, like we do
when the offset is out of bounds in the other direction.
Finally, when we get back more than one box from `getBoxesForRange`,
we were looking at the wrong end of the list: if we're looking
upstream, we want the end of the *last* preceding box, not the first
one. Similarly when looking downstream we want the start of the
first following box, not the last one. This was causing flutter#122477,
which I discovered while studying this code to diagnose flutter#50563.
Fix that too.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.