These shortcuts were ignored because the shortcut is built on top of the DefaultTextEditingShortcuts which prevented these shortcut from bubbling up.

I am not sure if this is the correct behavior, but there are tests to verify the arrow key does not cause scroll in CupertinoTextField, so I remove these shortcuts to maintain the same behavior

Maybe @Piinks knows? These shortcuts allow scrolling on a normal Scrollable, and I think they were not used by text inputs because the arrow keys move the cursor instead.

Maybe @Piinks knows? These shortcuts allow scrolling on a normal Scrollable, and I think they were not used by text inputs because the arrow keys move the cursor instead.

web can now handle test editing shortcut as long as the context in not inside TextField

"fired in TextField" => "fired when a TextField is focused"

Let me know if that's not what you mean. I think that's more explicit. Same for point 2 below.

By "swallowed" do you mean that Flutter ignores them and passes them through to the browser?

Which intents?

It's cool that this can be const now.

Ah I see, it took me a couple of times reading this code before I even realized there are 2 nested Shortcuts widgets now.

Can you explain these two situations in code? So in the app below running the code from this PR, I would expect that after tapping the button, ctrl/cmd - A would invoke SelectAllTextIntent, but it would not reach _SelectAllAction in EditableText due to the focus being outside of EditableText?

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  MyApp({Key? key}) : super(key: key);

  static const String _title = 'Flutter Code Sample';

  final FocusNode _focusNode = FocusNode();

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: _title,
      home: Shortcuts(
        shortcuts: {
          const SingleActivator(LogicalKeyboardKey.keyB, control: true): const SelectAllTextIntent(SelectionChangedCause.keyboard),
          const SingleActivator(LogicalKeyboardKey.keyB, meta: true): const SelectAllTextIntent(SelectionChangedCause.keyboard),
          //const SingleActivator(LogicalKeyboardKey.keyA, control: true): DoNothingIntent(),
          //const SingleActivator(LogicalKeyboardKey.keyA, meta: true): DoNothingIntent(),
        },
        child: Scaffold(
          appBar: AppBar(title: const Text(_title)),
          body: Center(
            child: Column(
              mainAxisAlignment: MainAxisAlignment.center,
              children: <Widget>[
                Focus(
                  focusNode: _focusNode,
                  child: TextButton(
                    onPressed: () {
                      _focusNode.requestFocus();
                    },
                    child: const Text('Press to focus me'),
                  ),
                ),
                const TextField(),
              ],
            ),
          ),
        ),
      ),
    );
  }
}

In this situation, in Web ctrl+A will first fire DoNothingAndStopPropagationTextIntent, but no one will handle it since the focus is above the TextField. It will then fire SelectAllTextIntent but still no one will handle it since the focus is above the TextField.

Understood and I verified this behavior on web and Mac with my code example 👍

"On web platform" => "On the web"

"makes sure" => "make sure of"

Shortcuts fired when an EditableText is focused are ignored and forwarded to the browser by the EditableText's Actions, because it maps DoNothingAndStopPropagationTextIntent to DoNothingAction.

Shortcuts fired when no EditableText is focused will still trigger _shortcuts assuming DoNothingAndStopPropagationTextIntent is unhandled elsewhere.

Once the above changes have been made to 1 and 2, remove this paragraph?

I think the docs here will be good with the changes above, but it has the effect of coupling DefaultTextEditingShortcuts and EditableText. Maybe that's not a big deal because the coupling is kind of inherent. Or we could be generic in the comments above to remove the coupling, but maybe it's not worth it?

I think this should be fine unless we would have other text editing widget that do no use EditableText.

Understood and I verified this behavior on web and Mac with my code example 👍

Nit: "Web Disabling Text Editing Shortcuts"?

Looking at other debugLabels in the codebase, most capitalize all of the first letters like this, but not all...