Can no longer visit positions in a block after a nested statement block

[microbit-robert]

Check for duplicates

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

Description

If you have an if/if else block and add a statement block inside one of the if... conditions, you can no longer visit any node in the parent if block after that statement block. In MakeCode, this also impacts access to the +/- modifiers to add / remove conditions. First noticed by @microbit-grace

I think this behaviour change was unintentionally introduced in #9104

Reproduction steps

Please see video below for reproduction.

Stack trace

Screenshots

Screen.Recording.2025-06-02.at.11.08.19.mov

Browsers

No response

[cpcallen]

I admit I have lost track of exactly what our official policy is re: visiting connections, but AFAICT the behaviour described above is working as intended per #9030.

We made unconnected input connections focusable in #9104. If we make unconnected stack connections focusable then that will complete the pendulum swing back to behaviour originally proposed in RaspberryPiFoundation/blockly-keyboard-experimentation#129 and implemented in RaspberryPiFoundation/blockly-keyboard-experimentation#143.

I'm broadly in favour of this—and not merely because I will feel very smug—but think that it is much less crucial now that we have excellent support for block-first insertion: at the time RaspberryPiFoundation/blockly-keyboard-experimentation#129 was written we were still using the marker, and had no way to move blocks, so being able to select an unconnected next connection was a critical feature. Now it is not, though it might still be useful and desirable.

[microbit-matt-hillsdon]

In the video, the unexpected behaviour is at the ~18 second mark when for some reason we no longer visit the "else if" test value input after adding the statement block. For another example, unexpectedly this field is the last position in this stack:

Either right or down will loop rather than visiting the rest of the stack.

[microbit-robert]

A simpler demonstration of broken navigation:

Screen.Recording.2025-06-10.at.11.05.58.mov

Needs a mouse click to move the cursor initially at the moment. The previous node at this point is the stack of two statement blocks. We then getRightMostChild which seems to only look at the first statement block in the stack, so the second statement block that we should navigate to is ignored.