Repository navigation
Add the ability to disable ContextMenu in TextFields #79796
Description
Activity
CC @justinmc
As discussed in #74255 (comment), I agree with the ability to disable the desktop context menus for now. Long term, we'd additionally like to make the built-in desktop context menus fully customizable, which is discussed in other issues like #74255.
Note that this also seems to be happening now with SelectableText as well.
Here you can see the built in context menu, rendering overtop of our own custom solution:
This is probably off-topic here, but for visibility:
I've just realized the built in menu seems to have non-standard behavior around dismissal. It is not dismissed when I click outside the menu. only when I click the text itself:
http://screens.gskinner.com/shawn/YLOWHoV7IB.mp4In ours we always sandwich a full-screen layer between the context menu and the rest of the app, so clicking anywhere dismisses it.
[Edit] Issue created: #80061
Hacky current solution
Right now, if you want to disable the right click menu in TextField, it's not easy and you'll have to copy a bunch of internal Flutter code. This is how you could do it:
- Copy the text_field.dart file into your own project, renaming it to something new (like MyTextField). Alternatively, modify your copy of the Flutter source code.
- Override the TextSelectionGestureDetectorBuilder in that file here so that onSecondaryTap and onSecondaryTapDown are noops.
@override void onSecondaryTap() {} @override void onSecondaryTapDown(TapDownDetails details) {}
The result will be that right clicking will have no effect for all instances of the modified TextField.
Can we add a parameter to do this?
It might not be a good idea to add a parameter to switch off the right click menu like this. Currently, these menus are very early and not finalized. This parameter would be a hack and would need to be deprecated and removed later as work continues on these menus.
Long term solution
Long term, the desktop right click menus should be a global menu not specific to text. They should be able to be used anywhere in your app, and they should be fully customizable. This would make it easy to disable them as desired in this issue, while also fixing many other problems they have right now.
From here
I think we should move towards the long term solution and resist adding a parameter for now. However, if someone has a strong case for being unable to use the hacky solution and needs a parameter in the near-term, then maybe we can reconsider.
Reacted by Rafał SobotaHey @justinmc I kinda missed this, just looping back to it now.
So for me, this is really frustrating. Flutter is such an easy and productive framework to build things in, but then it does stuff like this that is just inexplicable, shooting itself right in the foot.
Like, we had perfectly functional context menus. I spent a few days making them fully featured, beautiful, copying behavior from Windows/MacOS, polishing everything exactly as my designer wants. And then one day, Flutter just comes along and breaks them, replacing them with uglier, less functional versions. And then just leaves it in this broken state. Never thinking to itself, "hey if we're going to consume a bunch of gesture events, and show a non-styleable menu, we obviously need to allow developers to disable it".
I have created a lib here, which imo really eliminates the need for this to be native at all (it's actually not a big deal if you can't overflow the window chrome, with the right offset-logic): https://pub.dev/packages/context_menus but I think it remains partially broken / useless because of this issue.
I do appreciate the workaround, the obvious reason this is not great is because it immediately adds a significant chunk of Technical Debt in any project that employs it.
TextFieldis now out of sync with future fixes, team members need to be made aware of this special case, it becomes very easy for some team member to accidentally use the wrong TextField. What about selectableText? etcCan we add a parameter to do this?
It might not be a good idea to add a parameter to switch off the right click menu like this. Currently, these menus are very early and not finalized. This parameter would be a hack and would need to be deprecated and removed later as work continues on these menus.
The problem is, in the meantime, developers can't ship the product they want. It's a time-scale issue. If this will take 3mths, then your argument is totally sensical, there's not much point in adding a param. If we're waiting 2 yrs before we get full context-menu, then clearly a temporary 2-line fix is the pragmatic/reasonable solution, if we care about developers in the field actually being able to ship high quality products.
Also, I don't understand why this has to be deprecated. Even if you create a more full-featured system, wouldn't it be useful to still be able to turn it off at the widget level? You can't really predict fully what a developer might want to show on right-click...This seems similar to
ScrollBehavior. You can setScrollBehaviorfor the whole app, but you can also assign it to specific lists.Reacted by Jagmit Singh and ToniMHeinonenIf there are other more important priorities than desktop context menu, can we at least allow us to turn off the baked in stuff?
Q: Even if you are developing core ones, shouldn't we still be able to turn them off and have our own? If so, can't we just do that first?
This package is 200LOC at it's core, and does everything we need for beautiful robust context menus.
https://pub.dev/packages/context_menus
But it's basically unusable, because Flutter is implementing a partially baked implementation of its own, with no means to turn it off. So these menus will always clash with the ones from TextField, SelectableText etc
It feels like we need some movement here, as Flutter Desktop and Web is becoming more stable and used more frequently, the current context-menu solution is really not good enough.
It's quite frustrating when Flutter tries to do too much. An experience Flutter dev could build something like this in < 1 day, but when Flutter bakes this sorta of hard-coded behavior into core widgets like TextField, we become completely blocked, for years.
Reacted by Jagmit Singh, gaodeng and SteZhyvThis 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.- locked as resolved and limited conversation to collaborators
on Nov 11, 2022
In the case where we have implemented a consistent ContextMenu theme across the entire app, we would like to disable the built-in context menu and use our own instead. Currently the TextField widget swallows the RightClick event, so there is no way for us to override it. See this comment for more specifics: #74255 (comment)
@justinmc