Rethink ephemeral focus changes that relate to dropdown/widget div

[microbit-matt-hillsdon]

We've been testing the widget/dropdown div changes from #9213 and #9216 and unfortunately we think there is too much breakage in MakeCode without a clear route to address for Friday's release.

Please can you revert the widget div PR and consider carefully whether to also revert the dropdown div PR? We lean towards reverting both and reconsidering the approach.

This will reinstate focus quirks for mixed mode scenarios where you click outside the workspace when a field edit is in progress and then tab back into the toolbox/workspace. Clicking on the workspace or in MakeCode, using Cmd+B, 4 will fix it. We prefer a mixed mode bug with a workaround to a core keyboard nav flow bug.

Problems in blockly-samples field slider

Mainly just to illustrate it's not entirely a MakeCode thing and may affect others.

1. Drag out e.g. this block

2. Click to edit the field
3. Click in the number input
4. Enter to confirm

Note that the block is not selected when it normally would be. This is because focus was returned when you clicked outside the dropdown even though a widget was still open.

This is caused by #9213

You can see the problem more clearly by adding the keyboard nav plugin to the test page and using keyboard interactions except step 3.

Problems in MakeCode

They are essentially the same but more prominent and with significant impact on the keyboard navigation feature. We have several field editors which augment number field with a dropdown part to implement a combobox experience or an associated slider similar to field-slider but where the input can also be interacted with.

For keyboard navigation we use up/down to move between these two parts which works well.

But now moving away from the widget part removes the widget part entirely leaving a stranded dropdown. The user experience is that they cannot move back up to the widget.

If the user does use escape to close the dropdown part that they're stuck in then focus is not correctly returned and we end up with passive focus on the field.

This is caused by #9216 (because it's the widget taking ephemeral focus).

Example: combo box

Screen.Recording.2025-07-09.at.15.08.22.mov

Example: slider

Screen.Recording.2025-07-09.at.15.09.42.mov

Potential solutions

We've tried showing the widget part with autoCloseOnFocusLost false:

• this means the widget doesn't close which reinstates the ability to move back and forth
• pressing enter in the dropdown part still results in passive focus on the field
• the dropdown part no longer closes when clicking outside the workspace, with no clear route to fix
  • we can call DropDownDiv.hide() but that focuses the workspace
• this might not always be an easy change to make to a field

Trying to manage focus ourselves using the focus manager led to largely the same problems.

Prior to the above PRs, calling hideChaff at the right point was a workaround we were considering. It doesn't seem to have these issues but it's a pain to decide when to do it as we have to allow focus moving between workspace/widget and dropdown divs and only hideChaff when moving outside them as a group. We think this solution can't help us with the above PRs in place, but it could be an alternative, perhaps in MakeCode as a follow-up to the release ahead of another solution in Blockly.

Otherwise I think a careful rethink of the right API to offer such fields is needed, particularly when they pair fields like number with a dropdown div.

[BenHenning]

Apologies--this is a problem I've been spending a lot of time thinking about. I originally had a longer write-up to make on the other issue, but then realized that I thought I had a solution.

Part of this is also messy because I didn't quite have enough time yesterday to double check blockly-samples. I think we would maybe do well with adding more tests for various field plugins that could cover some of these ephemeral cases, though it's tricky because the failure mode mostly requires keyboard navigation (though there are some click-only scenarios that crop up with this functionality, too). I was expecting potential issues with drop down + widget div, and I'm hoping all of the issues only occur with both together.

Finally, I do want to say that even though it's easiest to hit these broken focus states in mixed mode with clicking, you can also do so with tab navigation when in field editor mode.

As for a fix, this does sound like the behavior that's causing the most problem is probably the change to returning ephemeral focus. #9213 made it so that if the div with ephemeral focus or its children lose DOM focus while in ephemeral mode, FocusManager will not return focus back to the marked focusable node when ephemeral focus ends. This fixes scenarios where you click out of a field editor into a combo box--we don't want to force focus back to the workspace. That being said, it's pretty clear why the multiple div scenario fails with this logic.

I need to think more before I type up my thoughts on properly solving this, and it realistically could involve a complete overhaul in how we think about focus for widget and drop-down divs (given the growing pile of issues these are causing with focus). As for the immediate fix, I actually suspect we probably can make some form of this focus logic work, so I'm inclined to conditionally disable the new behaviors rather than outright remove them. That should be a safer change and may even allow you to customize it on a case-by-case basis to fix it in some cases.

[maribethb]

Closing since we reverted, reopened google/blockly-keyboard-experimentation/#563