The basics

• I validated my changes

The details

Resolves

Fixes #8852

Proposed Changes

• Adds a KeyboardNavigationController singleton that has methods for setting keyboard navigation as active or not.

See matching PR in kbe RaspberryPiFoundation/blockly-keyboard-experimentation#555

Additional Information

The idea behind this is explained in #8852

When a user takes a "mouse action" like dragging blocks or the workspace with the mouse or right-clicking a block, then we decide they're not using keyboard navigation and remove the css class.

When a user takes a "keyboard action" like pressing m for move mode, using the arrow keys to navigate, pressing w to get a workspace cursor, etc. we add the css class, which can be used to show additional styling such as passive focus in certain circumstances. So far these keyboard actions are only present in the keyboard-experiment plugin, so core will never set the value to true, so there's no way for this to affect projects that aren't using the keyboard plugin.

There are some ambiguous actions like using the keyboard to copy/paste that are frequently done by both mouse and keyboard users. Those actions do not update the mode one way or the other.

In this PR I also chose not to change the mode for simple block clicks. The reason is that Ben pointed out that for mixed-mode users, clicking might be simpler with the mouse (or a tap on touch devices) while other actions use keyboard shortcuts. I think the current behavior is good. It starts as false, so a mouse-only user won't ever see the extra styling for keyboard users. Keyboard users will see the extra styling when they take any of several common actions with the keyboard. Mixed mode users will largely always see the extra styling unless they use the mouse to drag blocks. This is an improvement over the current input mode tracking in the plugin which does not handle the ambiguous cases noted above.