Keyboard shortcuts handled with the wrong scope

[microbit-robert]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

There is a keydown listener on the widget div. When we use arrow keys, this listener is triggered. The listener checks to see if the element is a text input or similar and ignores the event if that's the case. Otherwise, the keydown event is passed to the shortcut listener. The shortcut listener attempts to handle the keydown event, and the scope is the currently focused node. This code ignores whether anything has taken ephemeral focus. The focused node is the last field that was focused before the field editor was opened. Therefore, arrow keys move the cursor around the workspace in the background. This is problematic for a complex field editor in MakeCode that uses the widget div.

This doesn't currently happen with dropdown divs, but this is due to another bug where the keydown listener is removed from the dropdown div and not reinstated. I think that when this PR goes in, regular dropdown fields will also exhibit this problem.

I think a possible fix for this that the call to getFocusedNode here must take into account ephemeral focus.

Reproduction steps

The easiest way to reproduce this is probably to run the blockly-keyboard-experimentation repo locally with a linked Blockly repo that has the code changes in #9085 checked out.

You can then:

• add a show icon block
• navigate to the icon field with keyboard
• hit 'Enter' to open the field editor
• move the cursor on the workspace in the background with the left and right arrow buttons (minor visible change for the first move, invisible after that)
• hit 'Enter' again to trigger an action whether the cursor now is

See video below for an example of this.

Stack trace

Screenshots

Screen.Recording.2025-05-27.at.16.36.59.mov

Browsers

No response

[BenHenning]

This is a really good edge case that I hadn't considered for focus before. Ephemeral focus was meant to be designed to be hands off for specifically the cases when something outside of the core Blockly components held focus temporarily. This scenario is indicating that there's a case where Blockly still needs to have input focus for something that's not a core component.

This is a possible design oversight in FocusManager and would need some thinking to fix properly.

A shorter term fix may be to expose the previously focused node from FocusManager and also whether ephemeral focus is currently held. I think the latter is a reasonable long-term API addition, but the former is definitely a hack we will not want to keep forever as it could introduce unintended consequences (one example: deleting a block would populate the previously focused node even though the block doesn't exist anymore, at least until focus shifts a few times to overwrite it).

[maribethb]

This scenario is indicating that there's a case where Blockly still needs to have input focus for something that's not a core component.

I'm not sure that's totally true. In this case the keyboard shortcuts should probably just have their preconditions fail -- the arrow keys shouldn't do their default keyboard navigation behaviors if something is holding ephemeral focus. We do need to know if there is something holding ephemeral focus, so that we can either check that in the precondition, or check it when we pass the scope to the shortcut (either as a new property in scope, or potentially claiming that there is no node focused when something is holding ephemeral focus).

[microbit-matt-hillsdon]

@maribethb's assessment matches how @microbit-robert and I think about this issue.

Since #9085 was merged, this now affects dropdowns too.

Repro with latest experiment + blockly (note that doesn't seem to be what's currently deployed as the demo):

1. Add "draw ❤️" block after "draw circle"
2. Open dropdown (even via mouse)
3. Press left, left, enter
4. Note selection is now on "draw circle"

[maribethb]

Well, I was going to propose that we just don't fire any shortcut handlers if something has ephemeral focus, but #9085 sort of does the opposite of that. The two options I see are:

• don't fire any shortcut handlers if something has ephemeral focus - this could be done in the global event handler that calls the shortcut on key down. This would mean if a dropdown/widget div did intend to handle any kind of keyboard action, it would need to register its own keyboard event handlers.
• have each registered keyboard shortcut precondition check if something has ephemeral focus and then return false if so. each shortcut needs to do the same check.

the first option seems more straightforward to me but could require more work from people who do want their shortcuts to work in widgetdivs.

[microbit-matt-hillsdon]

We did a bit of digging as I was puzzled as to why this wasn't an issue for April user testing.

We think widget/dropdown content has always been closed/cleaned-up via the hideChaff call in the "escape" shortcut in core. So at least that shortcut needs to run when widget/dropdown div content has ephemeral focus. I guess it could be exempted by name from a "don't fire" check as it really is one of a kind, or some other way could be found to allow shortcuts to opt-in to being called during ephemeral focus (or a ton of precondition changes everywhere). I lean towards escape being a one-off here. RaspberryPiFoundation/blockly-keyboard-experimentation#560 now has a monkey-patch version of this to illustrate.

Back in April, this worked because we returned Constants.STATE.NOWHERE from navigation.getState(), which would have been set by a blur listener from one of the other states when focus moved to a dropdown or similar. Since the focus changes the state is a function of the FocusManager state. Back then, the navigation state was a systematic keyboard nav precondition check. Not so sure that's now true for e.g. copy/paste since the move to core.