Good call, these awaits probably should have been here.

This problem where RenderEditable is out of date is a recurring problem. I think using an addPostFrameCallback is the best option for now.

Indeed, it is a bit prone to more bugs. For bringIntoView() itself, I can see it's called from:

• text_selection.dart: handleSelectAll(), _handleSelectionHandleChanged()
• [material|cupertino] text_field.dart: _handleSelectionChanged()
• selectable_text: _handleSelectionChanged()
• editable_text: copySelection(), cutSelection(), pasteText(), selectAll(), _scrollToDocumentBoundary(), _updateSelection(), _expandSelection()

The only two calls that may modify text contents/layout are cut and paste, handled by this PR so this should suffice for now.

BTW, another question (unrelated to this PR) is whether only calling bringIntoView() on SelectionChangedCause.toolbar is desired behaviour. This means that if one cuts/pastes in an area outside of the viewport using keyboard shortcuts, we don't scroll there so the user won't see what's been done to the text.

Glad that this PR will handle the problem here at least.

About scrolling on paste, I think you're right that it's incorrect. I've created an issue: #98675.

What corner case is this handling exactly? Maybe consider adding a test that covers this (unless I misunderstand and the existing test does cover it).

Imagine you type "Lorem ipsum", select "ipsum", copy it and paste it into the same selection. Theoretically this is user input so you'd like to scroll, reset the caret animation, update selection/toolbar overlays etc. But
_didChangeTextEditingValue() won't be called because:

• it's a listener on TextEditingController which is a ValueNotifier<TextEditingValue>
• TextEditingValue equality operator will see the same value (text, selection, composing)
• ValueNotifier's value setter won't call notifyListeners()

So further, since _didChangeTextEditingValue() isn't called, the widget won't be updated and there won't be a post frame callback with bringIntoView() either.

The interesting thing is that the "Selection will be scrolled into view with SelectionChangedCause" test in editable_text_test.dart already caught that although perhaps it wasn't intentional. What it does is to set a (0, 1) selection on each call to resetSelectionAndScrollOffset() and then do 2x cut and 2x paste. So you always end up pasting the same character that's already there.

In the example you gave, wouldn't there be a selection change?

1. "Lorem [ipsum]"
2. Paste "ipsum"
3. "Lorem ipsum|"

Just tried in a TextField - no selection change on paste. In MS Word though, selection changes to collapsed on pasted text end, so it does in Chrome and VS Studio so it looks like this is the natural way of things.

Ah you're right, that's a bug in Flutter. Ok then I think this PR is fine. I'll look into fixing this bug. I tried on native Mac and Android and it collapses after a paste on both.

#98677

Great, thanks for submitting the two issues!

Does it make sense to move this to the pasteText method?

Currently _replaceText() is called from:

• cutSelection()
• pasteText()
• ReplaceTextIntent used by _DeleteTextAction

On cut and delete, the extra if(...) _didChangeTextEditingValue will be a no-op as text value should change. Given possible future uses of ReplaceTextIntent won't it be better to leave this in _replaceText()? (e.g. an intent to replace a selected text with the same text coming from semantics, scribble etc.

My intention was to avoid bundling side effects that are sometimes unexpected (such as this one) into generic operations like replacing text. It's a bit cleaner that way IMO especially when you are reading the code in pasteText, and you'll know immediately this is going to bring the new selection into view, instead of having to trace to _replaceText and find the "bring into view" logic there. But it's just a nit.

Does it make sense to move this to the pasteText method?