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.Dismiss alert
The copy/paste toolbar is always positioned above the selection. We should position it below the selection if it is too close to the top of the screen.
@parsodyl I hope to work on this soon. There is a major bug with this where the selection menu is overlapping the cutout, which was pointed out in the duplicate issue above.
This problem (selection menu is overlapping the cutout) is a main block for releasing our application. So we have to speed some time to fix it. Is this problem pull request welcome? @justinmc
change the position smarter. Put some safe space at top of screen, when TextField intersects with safe space, position toolbar below the TextField.
Add a property such as overlayPosition to TextField, let developer to decide proper position. When desired position is not safe, use the offsite position.
Android and iOS choose 1st solution. Tooltip widget chooses 2nd solution.
I prefer 2nd solution, which brings more freedom when TextField is in the middle.
@loongliu You'd make a lot of people happy if you submitted a pull request for this! It's definitely welcome.
I agree that we should try to make this solution follow what Tooltip does. We should try to reuse as much code as possible between the two. Take a look at _TooltipPositionDelegate and how it uses positionDependentBox. positionDependentBox seems like something we should reuse for this. Maybe even create a common widget shared with Tooltip that uses it?
I'm a little confused. Should the copy/paste menu now not be displaying under the appbar (or other obstructions) after the PR mentioned above? Because it's still happening for me. Sorry if I'm misunderstanding the fix.
@jlund24 In your case the menu should appear on top of the appbar, and this issue's fix shouldn't affect you. Is anything complicated happening in your main view that could affect the stacking order? Here is what I see on master:
@justinmc possibly, the textfields are in a Reorderable listview. The copy/paste menu also seems to cause an error talking about paint order when reordering with the menu open which I'm guessing is related. Would the list view be forcing some strange stacking behavior?
I can create a separate issue with an example if that would be more appropriate since it sounds like my issue is different than the one this thread is concerned with
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.
Activity
Hixie commentedon May 17, 2016
There's logic in the tooltip code to do something similar, might be able to factor it out into a reusable component.
xster commentedon Jan 4, 2019
From #20692 remember to avoid placing the toolbar above the selected text itself when avoiding the edge.
From #25632 remember to avoid placing the toolbar into the safe area when avoiding the edge.
mikuhl-dev commentedon Feb 3, 2019
Someone just pointed this out in my app. Embarrassing I cannot fix it.
parsodyl commentedon Feb 4, 2019
Any update on this?
justinmc commentedon Apr 2, 2019
@parsodyl I hope to work on this soon. There is a major bug with this where the selection menu is overlapping the cutout, which was pointed out in the duplicate issue above.
4 remaining items
justinmc commentedon Apr 3, 2019
Thanks for the clarification 👍
loongliu commentedon Apr 8, 2019
This problem (selection menu is overlapping the cutout) is a main block for releasing our application. So we have to speed some time to fix it. Is this problem pull request welcome? @justinmc
loongliu commentedon Apr 8, 2019
Generally there are two solutions.
Android and iOS choose 1st solution. Tooltip widget chooses 2nd solution.
I prefer 2nd solution, which brings more freedom when TextField is in the middle.
justinmc commentedon Apr 8, 2019
@loongliu You'd make a lot of people happy if you submitted a pull request for this! It's definitely welcome.
I agree that we should try to make this solution follow what Tooltip does. We should try to reuse as much code as possible between the two. Take a look at _TooltipPositionDelegate and how it uses positionDependentBox.
positionDependentBoxseems like something we should reuse for this. Maybe even create a common widget shared with Tooltip that uses it?justinmc commentedon Apr 8, 2019
Looks like there is already an outstanding PR that should solve this: #29809
@loongliu I'm interested in your feedback on that PR if it solves your problem!
justinmc commentedon May 6, 2019
This is now fixed with #29809.
To get the changes, you'll need a Flutter version greater than 1.5.8, or for now you can use the master channel.
jlund24 commentedon Jun 27, 2019
I'm a little confused. Should the copy/paste menu now not be displaying under the appbar (or other obstructions) after the PR mentioned above? Because it's still happening for me. Sorry if I'm misunderstanding the fix.

justinmc commentedon Jun 27, 2019
@jlund24 In your case the menu should appear on top of the appbar, and this issue's fix shouldn't affect you. Is anything complicated happening in your main view that could affect the stacking order? Here is what I see on master:
jlund24 commentedon Jun 27, 2019
@justinmc possibly, the textfields are in a Reorderable listview. The copy/paste menu also seems to cause an error talking about paint order when reordering with the menu open which I'm guessing is related. Would the list view be forcing some strange stacking behavior?
jlund24 commentedon Jun 27, 2019
I can create a separate issue with an example if that would be more appropriate since it sounds like my issue is different than the one this thread is concerned with
justinmc commentedon Jun 27, 2019
That could be it... Yes please open a new issue. If you can, try to pare down the problem into a minimal app and include it in the issue.
jlund24 commentedon Jun 27, 2019
Created a new issue that can be found here: #35227
github-actions commentedon Aug 17, 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.