Navigation after field edit broken by recent change

[microbit-matt-hillsdon]

1. Go to https://google.github.io/blockly-keyboard-experimentation/
2. Use keyboard navigation to edit the canvas width
3. Attempt to continue keyboard navigation and find you're stuck in the field

You can rescue it with shift-tab tab.

This regressed in #126.

CC @BenHenning

[microbit-matt-hillsdon]

We think the problem is that when editing fields, focus moves to the widget or dropdown divs and then never moves back to the workspace. Workspace focus is now a precondition for the key events. We need to return the focus to the workspace (or later, perhaps the block) after the field edit.

This issue makes it difficult to test/explore MakeCode's field editors with the latest version of the plugin.

[BenHenning]

Thanks for filing this @microbit-matt-hillsdon.

The ultimate issue here is that we now (as of #126) require focus of the Blockly workspace in order for keyboard navigation to be enabled, and the field input editors live as singletons outside of the workspace which means focus to the workspace is lost when those editors gain focus. The latter is an existing issue in core Blockly that has been around I think since the start of Blockly.

The reason this wasn't an issue before is because technically the keyboard events are global and thus it was possible to operate keyboard navigation regardless of focus (original plugin behavior) or based on an internal logical flag (the behavior before #126).

@gonfunko is considering a broader core Blockly change that would bring singletons like the input field editors into the injection div which would, indirectly, fix this issue. The alternative is to try and restore focus after input editing. From investigation it seems that this isn't something we can do via the plugin and would also require a core Blockly change. We're probably going to implement something like this farther in the future, anyway, since we need to introduce the concept of dynamic focus in order for keyboard navigation to correctly trigger readout from an active screenreader. With @gonfunko's change, however, we can possibly wait on that exact part of dynamic focus until later when we bring it from the plugin (where it will be initially implemented) into core Blockly.

[rachel-fenichel]

@BenHenning can you restore focus after input editing with a monkeypatch on core in order to unblock some testing? The long-term solution would need core to be aware of the navigation code and that's not happening in the next short while, so a monkeypatch is appropraite.

[rachel-fenichel]

@microbit-matt-hillsdon I added #156 which should broadly make focus behave properly as long as workspace.markFocused() is called. That means that if you get stuck in a bad state (e.g. from the toolbox) your first fix should be to call markFocused and see if it unwedges.

Note that markFocused is in core--I've just set it up so that we call the navigation one on the focus event.

[microbit-matt-hillsdon]

Workaround issues (I realise this isn't the plan but worth checking that an eventual fix doesn't have the same problems):

• As noted on the fix: add a focus listener on the parent svg #156 it reintroduced the extra tab stop .
  • Since addressed by fix: suppress tab stop due to focus listener #207
• Immediately after load, if you try to pan the workspace by mouse click & drag in empty space it now actually moves a block. You can only really see this in the test setup with the recent changes as it wasn't previously possible to pan, but if you revert a94d464 the problem goes away.

[microbit-robert]

I've just identified another unfortunate side-effect of the focus listener change made in #156. Any mouse click on the flyout now causes the flyout to close immediately. As a result, it is no longer possible to create a variable using the mouse.

Screen.Recording.2025-01-31.142451.mp4

[BenHenning]

The best thought I've had to fix this is to monkey patch FieldInput's widgetDispose_ since that's the moment to try and force focus back to the correct parent container, however FieldInput isn't exported so there's no obvious way (to me) to actually override that method currently. I'll need to keep exploring options next week on this.

[cpcallen]

however FieldInput isn't exported so there's no way to actually override that method currently

Not with that attitude. Have you tried:

Object.getPrototypeOf(Blockly.FieldNumber.prototype).widgetDispose_ = function(/* ... */) { // ...