Repository navigation
Selection controls don't move when their text widget is scrolled #3861
Description
Put an Input control inside a Scrollable view and select some text. When you scroll the view, the selection controls (handles and toolbar) don't move.
We need some way of informing the selection UI that the Input has been moved. We don't have a generalized way of doing this yet. @Hixie's thoughts on the matter:
so yeah, fundamentally the answer to your question is no, widgets (or more to the point, render objects), have no idea if they're being moved. This is an issue with, e.g., Material ink splashes; if you put a button in a rotating animation and the animation in a Material and tap the button, the splash will go all wrong.
we have a workaround for lists specifically, lists bubble a ScrollNotification. but that doesn't help in the general case.
there is a theory that one solution would be to do this at the layer level
we could have a layer that is pinned to the position of another layer
since that's the one tree that we do walk entirely each frame
so then whatever logic you wanted to do could be hooked up to the layer
e.g. if you wanted the selection handles to track the selection, you'd put the text field in a layer, the handles in a layer, and you'd tell the handles layer to track the global position of the selection layer
we don't have any support for this right now. @abarth might have ideas for how it should look, he's our layers guy.
Activity
mpcomplete commentedon May 11, 2016
Workaround for now:
mpcomplete commentedon Jul 28, 2016
Also note there are at least 2 Scrollables to deal with.
1 is easier to fix, because RawInputLine knows about the selection handles and can notify them directly when it scrolls.
2 is harder. Another option might be to allow arbitrary objects to subscribe to scroll notifications, and have the TextSelectionHandles walk up the widget tree, subscribing to scroll notifications from any Scrollable ancestor.
12 remaining items
eseidelGoogle commentedon Jun 1, 2017
Posse has identified this as a blocking issue for the app they're currently working on. Presumably due to it being easy to trigger and looking bad. :/
Hixie commentedon Jun 2, 2017
The plan is as follows:
Create two new layer types, LeaderLayer and FollowerLayer. They both take a "LayerLink" object, the LeaderLayer populates it with a reference to itself when it's attached and removes the reference when it's detached.
When a FollowerLayer is composited, it finds its LeaderLayer, and walks the compositor tree to find the common ancestor then determines the transform that goes from the follower's parent's coordinate space to the leader's coordinate space. It remembers this, and pushes a transform node into the scene builder.
When hit testing, that transformation is applied when traversing render objects that use the FollowerLayer.
I'll attempt to implement this next week.
eseidelGoogle commentedon Jun 14, 2017
Any update @Hixie? :)
Hixie commentedon Jun 14, 2017
Yeah, I'm half-way through writing a patch for this. The matrix maths is proving a little tricky. :-)
Hixie commentedon Jun 16, 2017
Ok I have a working fix, just need to do some cleanup.
github-actions commentedon Sep 4, 2021
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 -vand a minimal reproduction of the issue.