Skip to content

Conversation

@BenHenning
Copy link
Collaborator

@BenHenning BenHenning commented Feb 21, 2025

Fixes #180
Fixes #149
Fixes part of #101

The toolbox already had a tab stop, but it wouldn't become properly enabled for keyboard navigation. Now it is properly enabled and works when focused both via tab navigation and with the 'T' shortcut.

This has fairly substantial behavioral differences now:

  • Focus has been reworked to logically support either the toolbox or the workspace currently having DOM focus in order to support the toolbox properly having keyboard navigation support when enabled.
  • Keyboard navigation provided by core Blockly for toolbox has been monkey patched out since it would otherwise interfere with the toolbox navigation (and results in items being skipped when navigating through the categories).
  • The navigation controller now has support for a 'nowhere' state to support blurring the toolbox.
  • It's possible for the toolbox to have keyboard input with or without DOM focus which can result in some quirkiness when tabbing between the two--this may be something to iterate on if it introduces any user confusion.

From a long-term perspective, we may want to:

  • Limit some shortcuts to only cases when the workspace is focused (there's a behavior difference with either approach compared to the currently implementation).
  • Figure out a good way to ensure that these behaviors are properly captured in core Blockly as this plugin is moved over.

Separately, note that:

The new behavior can be seen here:

Screen.recording.2025-03-11.4.59.00.PM.webm

Note that the specific behaviors to observe are around how tabbing to the toolbox allows it to be focused and have keyboard navigation enabled. The video also demonstrates some of the awkward behaviors of switching focus between the toolbox and workspace when the other one is actually focused (such as when inserting a block from a focused toolbox or using the 't' command from an active workspace).

Note that this video also shows how subcategories are currently a bit buggy with left/right navigation (an existing issue now being tracked in #241):

Screen.recording.2025-02-24.4.34.35.PM.webm

The toolbox already had a tab stop, but it wouldn't become properly
enabled for keyboard navigation. Now it is properly enabled and works
when focused both via tab navigation and with the 'T' shortcut.
@BenHenning BenHenning marked this pull request as ready for review February 21, 2025 00:41
@BenHenning BenHenning requested a review from a team as a code owner February 21, 2025 00:41
@BenHenning BenHenning requested review from RoboErikG and removed request for a team February 21, 2025 00:41
@BenHenning
Copy link
Collaborator Author

@RoboErikG PTAL for approval.

@rachel-fenichel could you PTAL for the behavior in the video to make sure it looks good? I plan to ask @microbit-matt-hillsdon to take a look at this once it's merged, as well, to ensure it has good compatibility with MakeCode's toolbox.

@BenHenning
Copy link
Collaborator Author

BenHenning commented Feb 21, 2025

TODO: Self, double check if ||'s should be replaced with ??'s.

@microbit-matt-hillsdon
Copy link
Contributor

Interestingly this changes the behaviour for #222 and the flyout now switches from Variables to the first category after creating a variable.

We're a little worried this one might be hard for us to integrate ahead of user testing due to the toolbox interactions and we don't want to lose the ability to take other changes. We'll explore that today and get back to you.

@microbit-matt-hillsdon
Copy link
Contributor

We're a little worried this one might be hard for us to integrate ahead of user testing due to the toolbox interactions and we don't want to lose the ability to take other changes. We'll explore that today and get back to you.

We've since done a test merge of this change and it's neutral from the perspective of the MakeCode toolbox.

I was hopeful that if the flyout learnt to take focus we could simplify some of what we've done there. At the moment when we hand off from the MakeCode toolbox to the flyout (right arrow) we DOM focus the workspace and call navigation.focusFlyout so that we have working keyboard nav in the flyout. It feels weird to me to see a focus outline on the workspace due to that. Long term I was hoping that could just be us calling focus on the flyout. I think it could be useful for us to discuss the MakeCode toolbox hack we have now in the light of the plan on #142.

@RoboErikG
Copy link
Contributor

I'm not sure I understand the keyboard navigation pieces enough yet to do a quick review. Reassigning in case there's time pressure to get this in.

Copy link
Collaborator

@rachel-fenichel rachel-fenichel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense to me logically.

In the screencast I see that the text on all blocks in the flyout is highlighted as though selected. Please fix.

microbit-matt-hillsdon added a commit to microbit-matt-hillsdon/blockly-keyboard-experimentation that referenced this pull request Feb 24, 2025
This really helps with the route to the MakeCode sim and matches the behaviour on
RaspberryPiFoundation#225
@BenHenning
Copy link
Collaborator Author

We're a little worried this one might be hard for us to integrate ahead of user testing due to the toolbox interactions and we don't want to lose the ability to take other changes. We'll explore that today and get back to you.

We've since done a test merge of this change and it's neutral from the perspective of the MakeCode toolbox.

I was hopeful that if the flyout learnt to take focus we could simplify some of what we've done there. At the moment when we hand off from the MakeCode toolbox to the flyout (right arrow) we DOM focus the workspace and call navigation.focusFlyout so that we have working keyboard nav in the flyout. It feels weird to me to see a focus outline on the workspace due to that. Long term I was hoping that could just be us calling focus on the flyout. I think it could be useful for us to discuss the MakeCode toolbox hack we have now in the light of the plan on #142.

Thanks for checking @microbit-matt-hillsdon. Just to clarify: is there anything else you specifically need here ahead of the user test, or do you think the changes here are sufficient & compatible?

Re: the focus outline, I agree completely. It's confusing that the toolbox can hold focus but the workspace be receiving input and vice versa (both of which states are now made possible with this PR). The planned changes in #142 should fix that, though there will need to be a fair amount of reworking of the plugin to rely more on focus and less on presuming focus (i.e. Blockly elements need to actually have focus not just the indicator), but that's expected as part of the broader focus work.

This helps to verify subcategory behavior (which has been observed as
not completely working currently).
Copy link
Collaborator Author

@BenHenning BenHenning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Self-reviewed latest changes.

Thanks @rachel-fenichel. PTAL.

Copy link
Collaborator

@rachel-fenichel rachel-fenichel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for simplifying out the flyout case for now--please also file a bug to follow up on the flyout case, if we don't already have one.

@microbit-matt-hillsdon
Copy link
Contributor

microbit-matt-hillsdon commented Feb 25, 2025

Thanks for checking @microbit-matt-hillsdon. Just to clarify: is there anything else you specifically need here ahead of the user test, or do you think the changes here are sufficient & compatible?

There's nothing further we need here, thanks. If it is going to be merged before UT then the sooner the better from our point of view. We can live without it if needed just because the MakeCode toolbox already had these behaviours (and we've aligned them where this PR differed).

microbit-matt-hillsdon added a commit to microbit-matt-hillsdon/blockly-keyboard-experimentation that referenced this pull request Feb 26, 2025
This really helps with the route to the MakeCode sim and matches the behaviour on
RaspberryPiFoundation#225
@RoboErikG RoboErikG removed their request for review February 27, 2025 22:50
@BenHenning
Copy link
Collaborator Author

Thanks @rachel-fenichel. I followed up with a fix for the monkey patch installation--any concerns? It seems a bit awkward to me due to how early in the application lifecycle it needs to be 'installed'.

Re two earlier comments:

  • "please also file a bug to follow up on the flyout case, if we don't already have one." -- which flyout case do you mean?
  • "In the screencast I see that the text on all blocks in the flyout is highlighted as though selected." -- is this the flyout case? Regardless, I'm not sure that I fully understand what's observed as broken. Approximately which part in the video do you see the broken behavior (I admittedly should have slowed it down originally since it navigates through parts of the UI a bit quickly).

@rachel-fenichel
Copy link
Collaborator

The text on the blocks (if, do, etc) looks like it has been selected with the mouse on all blocks in the flyout. It looks like that's true for all categories.

blocks in the flyout with text highlighted

Also I shouldn't have merged my change before yours--sorry about the merge conflict >.<

rachel-fenichel
rachel-fenichel previously approved these changes Mar 6, 2025
@rachel-fenichel
Copy link
Collaborator

"the flyout case" meaning the case that there is a flyout with no toolbox.

Conflicts:
	src/navigation_controller.ts
It seems possible now to call hide() earlier than previously expected
(i.e. when there's a cursor but no current node, such as in the case of
focusing the toolbox before the workspace as this PR now makes
possible).
Copy link
Collaborator Author

@BenHenning BenHenning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Self-reviewed latest changes.

@rachel-fenichel thanks for the extra details on the text issue. It seems that it mysteriously went away after syncing to latest, so that's fun. :) If you could, PTAL at the latest changes just to make sure everything seems reasonable. I've enabled auto-merge so feel free to merge this, as well, if there are no follow-ups. The first video in the description has also been updated accordingly.

@BenHenning BenHenning dismissed rachel-fenichel’s stale review March 12, 2025 00:03

Dismissing so that I can enable auto-merge.

@BenHenning
Copy link
Collaborator Author

Hmm GitHub is very mysterious. I apparently don't need to get re-approval after dismissing approval to merge. Well, please go ahead and merge this upon approval if it looks good @rachel-fenichel otherwise I will tomorrow AM.

@rachel-fenichel
Copy link
Collaborator

Changes LGTM.

@BenHenning BenHenning merged commit 6327ca7 into RaspberryPiFoundation:main Mar 12, 2025
3 checks passed
@BenHenning BenHenning deleted the make-toolbox-properly-focusable branch March 12, 2025 00:05
gonfunko pushed a commit that referenced this pull request Mar 14, 2025
* feat: Make toolbox & flyout properly focusable.

The toolbox already had a tab stop, but it wouldn't become properly
enabled for keyboard navigation. Now it is properly enabled and works
when focused both via tab navigation and with the 'T' shortcut.

* chore: address reviewer comments

* feat: add subcategory to demo toolbox categories

This helps to verify subcategory behavior (which has been observed as
not completely working currently).

* Address reviewer comment for monkey patch install.

* Revert monkeypatch installation changes.

* Add fix for null current node.

It seems possible now to call hide() earlier than previously expected
(i.e. when there's a cursor but no current node, such as in the case of
focusing the toolbox before the workspace as this PR now makes
possible).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Remove spurious tab stop before workspace Toolbox with categories takes focus but doesn't indicate it or have working nav

4 participants