Use focus to denote cursor location

[cpcallen]

TL;DR

Moving the cursor should should move (browser) focus, and vice versa.

Background

History

This plugin uses LinceCursor, which is a kind of Marker, to denote the location the user has navigated to. Originally it always used the marker's dawer* (a MakerSvg instance) to denote the location of the cursor.

When marking a block, MarkerSvg draws a rectangle around the entire block and all it's child blocks. This behaviour seems unintuitive, especially when navigating stacks of statement blocks—we'd like just the individual block to be marked. In preparation for user testing on October 28 2024 we decided to fix this, but because changing MarkerSvg was non-trivial @rachel-fenichel opted to make a quick, kludgy fix #76 to use the existing block selection code to denote the cursor, when the cursor was on a block.

This was successful, insofar as the students participating in user testing generally did not get confused about the cursor location, and in post-testing discussions we realised that we probably do in most cases want navigating to a block to select that block: it is natural to navigate to a block and then use the delete/cut/copy shortcuts, in expectation that they will apply to that block (without the need to first place the marker or do something else to explicitly select the block).

* N.B.: that's draw-er—as in something that draws—not drawer!

Focus vs. Selection

It is helpful to distinguish focus from selection—in short, in the abstract:

• Only one item can have focus at a time; there should be a visible focus indicator at all times.
• Zero, one, or multiple items can be selected; there should be a distinct visual indicator to indicate which item(s) are selected.
• Moving focus may or may not change what is selected, e.g.:
  • In a typical spreadsheet, moving focus to a different cell selects that cell and unselects any previously-selected ones.
  • In a multiselect list box, moving focus does not change which items are selected.

Currently core Blockly does not have a distinct concept of "focus", and restricts selection to at most one block at a time. This plugin conflates focus and selection by using selection to denote the location of the cursor.

Proposals

Introduce focus; unify with cursor

We should introduce formal support for focus, separately from selection.

• This will probably entail adding support for focus in core Blockly, integrating this with the DOM's idea of what is focused, providing a visual focus indicator, and ensuring that clicking on a block or field focuses it.
• As previously discussed, we will probably want to use a roving tabIndex to manage browser focus, treating each workspace as a separate component with a single movable tab stop.

We should modify this plugin to denote the cursor location using focus, and move the cursor in response to focus changes, including by other means such as clicking on a block or field. Ideally we will unify focus and the cursor a single concept—but note that, as we wish to ensure that focus location within a workspace is maintained when tabbing (thus changing focus) between toolbox / flyout / workspace, it will be necessary to track "previous focus location" for each workspace—a task currently managed by each having its own cursor instance.

Move selection with focus by default

Per discussions noted above, moving the cursor/focus to a block should continue to select it, when possible, so that it will be the target of keyboard shortcuts such as cut/copy/delete. Since shadow blocks cannot be selected but need to be focusable (so that they can be navigated and their shortcuts menu accessed via the keyboard) we'll need separate focus vs. selection indicators.

We may in future wish to provide additional keyboard shortcuts to support multi-select.

In the interim

Until focus support is more fleshed out, this plugin should continue to use selection to denote the cursor location where possible.

See also

• Clicking on a block selects it but does not move cursor #97