Skip to content

Upgrade to latest Blockly keyboard navigation plugin #10512

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

microbit-robert
Copy link
Contributor

@microbit-robert microbit-robert commented Apr 10, 2025

We are opening this PR in draft mainly for visibility at this point. This PR has now been rebased on master after the upgrade to Blockly v12.0.0-beta.4, on which the new keyboard navigation plugin depends.

Link to demo. Please note that 'accessible blocks' need to be set to 'on' in the settings menu.

A summary of changes and blockers to the plugin upgrade are listed below:

  • Use blockly/keyboard-experiment v0.0.7
  • Remove toolbox tab stops and use arrow keys for toolbox nav
  • Improve area for toolbox
  • Add skip link for the workspace when keyboard nav is enabled
  • Remove second step to enable keyboard nav after enabling the experiment, the objective is always enabled keyboard nav.

Resolved blockers

  • MakeCode cut / copy / paste modifications are disabled to prevent conflict, next step needs discussion. The current implementation in MakeCode reuses Blockly code and hooks in localStorage to copy and paste between tabs - it is not clear if the same approach can be taken with the new keyboard plugin and needs investigation
    • Currently you need access to plugin internals to follow this route so exploring other options.
    • As a stopgap to enable moving forward with this PR, we could disable MakeCode's copy/paste overrides when the experiment was enabled.
  • We've sidestepped the caching MakeCode's flyout does (directly using CachingFlyout), to avoid breaking Blockly assumptions that the flyout / flyout workspace doesn't change over time. Caching is valuable though, need to explore reinstating perhaps at a different level.

Follow-up issues:

  • Help docs
  • Global shortcuts
  • Black focus outline around the toolbox, flyout and workspace, respectively, when using keyboard navigation. The workspace currently shows this outline on click which is not desired behaviour.
    • We think it's not so bad that this happens for a mouse click if you've enabled the keyboard nav experiment but it's not reasonable if we moved to enabling it by default. Propose tracking separately.
  • Avoid affecting theme
    • We're going to try to fix this in Blockly but I think they switched from yellow to orange for visibility reasons so it's worth considering making this change in MakeCode. We'll try to make the theme the source of truth for color for the selection color and the related cursor positions the plugin draws.
    • We discussed this on the last MakeCode call and agreed that the colour change was OK for users who opt-in to block keyboard navigation. Changing it globally is a discussion for the future.
  • It's common to hit the issue addressed by this PR so it would be good to agree a way forward for that: Clear system clipboard on block copy to prevent pasting files. #10463

@riknoll @microbit-matt-hillsdon

Closes #10464

microbit-matt-hillsdon and others added 8 commits April 22, 2025 11:54
Temporarily based on a micro:bit team upgrade-blockly-12 branch.

- Remove toolbox tab stops; use arrow keys for toolbox nav
- Add skip link for the workspace when keyboard nav is enabled
- Keyboard navigation plugin is using a tar file for now but we'll ask Blockly for a release soon and update
- Remove second step to enable keyboard nav after enabling the experiment, the objective is always enabled keyboard nav.
- Blockers:
    - [ ] MakeCode copy/paste modifications are disabled to prevent conflict, next step needs discussion
    - [ ] Caching flyout is used, sidestepping caching, to avoid breaking Blockly assumptions that the flyout / flyout workspace doesn't change over time. Caching is valuable though, need to explore reinstating perhaps at a different level.
    - [ ] Focus outlines for the workspace need discussion and are currently incorrectly showing for some mouse interactions. Maybe OK for the experiment but not for enabled by default.
The connection lines are rendered incorrectly when moving blocks
via keyboard, which use underlying drag methods.

Easier to disable them than to try and get the right coords.
@microbit-robert microbit-robert force-pushed the blockly-12-keyboard-exp branch from b8bf9fe to 4a542e9 Compare April 22, 2025 12:00
Comment on lines 556 to 565
const injectionDiv = document.getElementById('blocksEditor');
injectionDiv.classList.add("accessibleBlocks");
const focusRingDiv = injectionDiv.appendChild(document.createElement("div"))
focusRingDiv.className = "blocklyWorkspaceFocusRingLayer";
this.editor.getSvgGroup().addEventListener("focus", () => {
focusRingDiv.dataset.focused = "true";
})
this.editor.getSvgGroup().addEventListener("blur", () => {
delete focusRingDiv.dataset.focused;
})
Copy link
Contributor

Choose a reason for hiding this comment

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

This gives a more reasonable focus ring for the workspace, one that isn't occluded on the left hand side by the toolbox. We should discuss this with Blockly and potentially move the behaviour to the plugin (maybe with options for a better implementation).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We are continuing to have discussions regarding the focus indicators, but we propose moving forward with this change for this initial PR.

@microbit-matt-hillsdon
Copy link
Contributor

Agreed to restructure this around a setting rather than an experiment. Setting can reload the page.

@riknoll
Copy link
Member

riknoll commented Apr 24, 2025

re: copy/paste, i assume this means the blockly plugin is also broken? seems like this should be something tackled by the blockly team. for now, your suggestion of disabling it when the experiment is active seems like an acceptable temporary solution

i'll look into a plan for the flyout

microbit-grace and others added 4 commits April 30, 2025 11:56
)

- Removes accessible blocks onboarding dialog.
- Remove use of theme to determine accessible blocks enablement. 
- Changes in accessible blocks settings should persist via user accounts / local storage.
This copies over some internals from the Blockly keyboard
experimentation plugin and modifies them to suite our needs.

We would welcome suggestions from Blockly regarding a more
concrete solution.
Stop gap for cut/copy/paste conflicts with MakeCode
@microbit-robert
Copy link
Contributor Author

re: copy/paste, i assume this means the blockly plugin is also broken? seems like this should be something tackled by the blockly team. for now, your suggestion of disabling it when the experiment is active seems like an acceptable temporary solution

Yes, we think it has the same issue. We've now disabled the custom copy/paste overrides in MakeCode if the keyboard nav plugin is enabled as a temporary work around. We explored whether the copy/paste behaviour in the keyboard nav plugin could be implemented in MakeCode, but it requires access to internals. We will raise this with the Blockly team to get their view on the best solution @rachel-fenichel.

This replaces 'c' to clean up workspace
@microbit-robert
Copy link
Contributor Author

This PR is now in a state where it can be reviewed. Blockers have been addressed and the related follow-up issues will be tackled in follow-up PRs.

@microbit-robert microbit-robert marked this pull request as ready for review May 1, 2025 15:03
@microbit-robert
Copy link
Contributor Author

Just highlighting that the keyboard navigation plugin is at a somewhat arbitrary point in its development. Blocks inserted from the flyout are currently inserted in 'move mode', but this is not clear in this version. A move icon has been added since, but is not in this released version. You will need to hit "Enter" to confirm the block position before doing anything else.

I've added some information about the keyboard controls below, but expect this PR to be more about the integration, than the plugin behaviour itself as this will change with updates going forward.

The basic keyboard controls:
Screenshot 2025-05-01 at 17 37 30

Move mode controls:
Screenshot 2025-05-01 at 17 43 20

Copy link
Member

@riknoll riknoll left a comment

Choose a reason for hiding this comment

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

looks pretty good! just some minor comments

@riknoll
Copy link
Member

riknoll commented May 1, 2025

@microbit-matt-hillsdon here is an uploaded build with the changes from this PR:

https://makecode.microbit.org/app/5b64f555bd29c0c75350023549b02a28cb03c1b0-74c00c13f3

@riknoll riknoll merged commit 489df47 into microsoft:master May 5, 2025
12 checks passed
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.

Switch to latest Blockly keyboard navigation experiment
5 participants