Shift+Tab after keyboard navigating to a block doesn’t open flyout as expected

[sappm01]

Check for duplicates

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

Description

Shift+Tab after keyboard navigating to a block doesn’t open flyout as expected. There seems to be an extra workspace tab stop that causes the workspace outline to appear.

Ben: this is not a simple fix, and probably needs discussion. The workspace is a browser-level tab stop that we have some control on overriding to switch focus, but it's unclear if the user wants to be able to navigate back to the workspace. If we want to provide that functionality, it has to stay as a tabstop. We do override first-time focus on the workspace to select the first block (if one is present), but it is possible to navigate back to the workspace via shift-tab as described.

Reproduction steps

Stack trace

Screenshots

No response

Browsers

No response

[maribethb]

Needs more discussion -- some disagreement over whether the workspace should be a tab stop between the flyout and block

[maribethb]

I think the workspace should remain a valid tab stop

[rachel-fenichel]

@microbit-matt-hillsdon and @kmcnaught to discuss--Maribeth disagrees with the request (see above).

[BenHenning]

In google/blockly-keyboard-experimentation#511 (comment) I mentioned some thoughts on this. Specifically this bit:

• Extra tab stop issue for the workspace

Just to check, this is only for shift tabbing once in the workspace, correct? If so, this will require more discussion as there may be an explicit need to be able to tab to the workspace (to open the workspace context menu with redundancy/consistency with regular keyboard navigation).

There's a small chance a proper long-term fix here would require breaking API changes. The unknown is how to let WorkspaceSvg signal to FocusManager what to do when the root is focused (which we have no control over--this is a DOM event). In some contexts we want to auto-focus a node, but in others we want to either focus the workspace or skip it. This could get complicated.

[microbit-matt-hillsdon]

At the moment if you tab to the workspace en route to the toolbox/flyout you lose your cursor position as it moves to the workspace which is unlikely to be what you want.

I think the workspace position should be more like a special block position and not itself accessible via tab.

I've been using this branch to visualise the current behaviour more clearly with a custom focus ring for the workspace when it's the active tree and a selection-style ring when its the active node.

Perhaps this plan could require making something like that latter ring represent the workspace in the DOM similarly to a block.

[microbit-matt-hillsdon]

FWIW I think it's OK for it not to open the flyout, understandable given its transient nature. But I do think the behaviour we used to have (still in deployed demo at time of writing) where you could shift tab back to the toolbox was really helpful.