Toolbox flyout navigation becomes permanently broken after trying to select a FlyoutButton

[BenHenning]

Check for duplicates

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

Description

Attempting to navigate to a flyout button with keyboard navigation permanently breaks flyout navigation.

Reproduction steps

1. Check out 8a9e9d9.
2. Ensure that it's updated to use v12 beta.7 and has been correctly npm install'd and npm ci'd.
3. Start the local test environment with npm run start.
4. Open the test environment locally and tab navigate to the toolbox.
5. Use down arrow keys until the Variables category is selected.
6. Press the 'right' arrow key to move focus to the flyout.
7. Press the 'left' arrow key to move focus back to the toolbox.
8. Attempt to navigate to any toolbox category flyout and notice that the highlight no longer works. It's also not actually hidden, it's truly not selecting (since blocks cannot be inserted anymore).

Stack trace

N/A

Screenshots

Video repro:

Screen.recording.2025-05-15.12.48.59.PM.webm

Browsers

No response

[BenHenning]

Noticed when testing #511 locally.

[BenHenning]

Confirmed with a local bisect that this started failing with RaspberryPiFoundation/blockly#9032. Not yet sure why.

[BenHenning]

So it has something to do with this logic:

https://github.com/google/blockly/blob/a1cbdd9107318ec7b061976c6a689b6fb264081a/core/keyboard_nav/line_cursor.ts#L380-L383

From testing I think there's some sort of de-syncing happening between the cursor and focus wherein focus automatically adjusts opening the flyout to its first element (the FlyoutButton in the case of the Variables category), but this doesn't reflect in cursor (at the time of getCurNode being called it thinks the current focus is on the flyout's workspace). Since this logic leads to the flyout workspace becoming the node, navigation starts choking since it doesn't really know how to recover from that (I didn't dig into that part, but I'm assuming it has to do with there maybe being no way to navigate relative to the flyout's workspace).

This can be fixed by changing the logic to limit the node syncing only to block cases since then we'll know for sure those will work (and not regress #499), but this is probably another indicator that we should remove LineCursor/Marker's own state syncing in favor of always reflecting the focus system.