EditableText should handle shortcuts related to text formatting without overriding with Shortcuts #174758

Activity

1. justinmc commented on Aug 31, 2025

   

   justinmc

   on Aug 31, 2025

   Contributor

   More actions

   I know about the suggested workaround in cases like this in the section Interactions Between Shortcuts and Text Input but that is not feasible for any app that uses dynamic shortcuts configuration like this one https://github.com/orestesgaolin/flutter_desktop_sandbox.

   Can you explain in more detail why that approach won't work in your app?

   This is probably a situation where Flutter needs to provide the ability to support both use cases. I imagine there are valid reasons to capture diacritic keyboard shortcuts.
2. orestesgaolin commented on Aug 31, 2025

   

   orestesgaolin

   on Aug 31, 2025

   ContributorAuthor

   More actions

   Can you explain in more detail why that approach won't work in your app?

   It's not possible to get all defined text field shortcuts to cancel them out, even if I wrap TextField with DefaultTextEditing shortcuts.

   An extreme case of that is setting single key shortcuts which will override typing a given letter, see video below (this is not overridden with custom Shortcuts, just overridden with DefaultTextEditingShortcuts):

   screenshot_20250831_163052.mp4

   This behavior can potentially be overridden if I wrap TextField with something like below i.e. single keys will always be ignored (this does not exclude single activators for function keys or any other special purpose keys):

     Map<ShortcutActivator, Intent> getTextFieldShortcuts() {
       final definedKeys = shortcuts.map((s) => s.keys);
       final definedSingleKeys = definedKeys.where((e) => e.triggers.length == 1).expand((e) => e.triggers);
   
       return {
         for (final key in definedSingleKeys) SingleActivator(key): DoNothingAndStopPropagationIntent(),
       };
     }

   The more I think about it, the more it seems that there are only text editing shortcuts with meta and alt key (which are provided with DefaultTextEditingShortcuts e.g. alt + arrow left or cmd + a) and extra characters with alt key (e.g. alt + a resulting in diacritics ą). So in theory if I have any shortcut that includes any of the alt keys, I should be able to cancel it with something like this:

   Map<ShortcutActivator, Intent> getTextFieldShortcuts() {
       final map = <ShortcutActivator, Intent>{};
       final definedKeys = shortcuts.map((s) => s.keys).toList();
       final definedSingleKeys = definedKeys.where((e) => e.triggers.length == 1).expand((e) => e.triggers); // todo: ignore function keys
       final definedWithAlt = definedKeys.where(
         (e) =>
             e.triggers.length == 2 &&
             (e.triggers.contains(LogicalKeyboardKey.alt) ||
                 e.triggers.contains(LogicalKeyboardKey.altLeft) ||
                 e.triggers.contains(LogicalKeyboardKey.altRight)),
       );
   
       for (final key in definedSingleKeys) {
         map[SingleActivator(key, alt: true)] = DoNothingAndStopPropagationIntent();
       }
   
       final altKeys = definedWithAlt
           .expand((e) => e.triggers)
           .where(
             (e) => e != LogicalKeyboardKey.alt && e != LogicalKeyboardKey.altLeft && e != LogicalKeyboardKey.altRight,
           )
           .toSet();
   
       for (final key in altKeys) {
         map[SingleActivator(key, alt: true)] = DoNothingAndStopPropagationIntent(); // include alt keys!
       }
       return map;
     }

   and then use like this:

       child: DefaultTextEditingShortcuts(
         child: Shortcuts(
           shortcuts: getTextFieldShortcuts(),
           child: EditableText(

   This ensures that even if user defines alt + a shortcut, the text field will behave as expected. It's a bit of whack-a-mole game because there may be some more text specific shortcuts that I didn't think of to cancel. Anyway, it seems that this is sufficient for me to provide:

   • DefaultTextEditingShortcuts
   • Shortcuts with map of shortcuts cancelling out any potential user-defined shortcuts that include alt

   screenshot_20250831_165447.mp4

   All in all, it seems that for my purposes I should be able to find workarounds in existing framework code, although it would be still useful to redefine text editing shortcuts like suggested in #97830. Hence, I'm closing my issue in favor of #97830.
3. orestesgaolin

   closed this as completedon Aug 31, 2025
4. github-actions commented on Sep 14, 2025

   

   github-actionsbot

   on Sep 14, 2025 – with GitHub Actions

   More actions

   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.
5. github-actions

   locked as resolved and limited conversation to collaborators on Sep 14, 2025