Fix iPad toolbox interactions; unify Monaco toolbox on the click path#11404
Open
microbit-matt-hillsdon wants to merge 1 commit into
Open
Fix iPad toolbox interactions; unify Monaco toolbox on the click path#11404microbit-matt-hillsdon wants to merge 1 commit into
microbit-matt-hillsdon wants to merge 1 commit into
Conversation
The Monaco toolbox drove category selection from a pointerup handler with the trailing click swallowed, because the first toolbox tap after the editor's textarea had focus produced no synthesized click. The category selection by id was broken by recent changes to the category ids to scope them by editor. These are now correctly scoped. But it turns out the missing first-tap click is an interaction of the pointerdown preventDefault and the manual tree focus() together; with both removed the click fires normally. So Monaco now activates on click like the blocks editor: handlePointerDownCapture only suppresses focus-driven selection for the gesture (no preventDefault, no focus steal), and the pointerup handler and click suppression are gone. Long-press text selection, previously suppressed by preventDefault, is handled with user-select: none on the tree. Both editors now share the click path and the toolbox code is simpler. User-visible change (iPad Safari, Monaco alignments to Blocks behaviour unless noted): - Tapping a category, or the "...more" entry, opens its flyout. Previously these taps did nothing due to the id issue. - Tapping the Advanced (...) toggle expands/collapses once, instead of opening then immediately snapping shut. - Re-tapping an open category closes its flyout instead of reopening it. - Closing a subcategory's "...more" flyout keeps its parent category expanded and selected, instead of collapsing it and jumping the highlight to the next category. - Collapsing the Advanced section no longer jerks the whole toolbox up under the header. - Switching between categories swaps the flyout contents in place instead of the flyout visibly disappearing and reappearing.
srietkerk
approved these changes
Jun 12, 2026
srietkerk
left a comment
srietkerk
left a comment
Contributor
There was a problem hiding this comment.
This looks awesome, thank you so much!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Monaco toolbox drove category selection from a pointerup handler with the trailing click swallowed, because the first toolbox tap after the editor's textarea had focus produced no synthesized click.
The category selection by id was broken by recent changes to the category ids to scope them by editor (#11382, breaking @srietkerk's fix for microsoft/pxt-microbit#6802 - sorry!). These are now correctly scoped in this PR.
But it turns out the missing first-tap click is an interaction of the pointerdown preventDefault and the manual tree focus() together; with both removed the click fires normally. So Monaco now activates on click like the blocks editor: handlePointerDownCapture only suppresses focus-driven selection for the gesture (no preventDefault, no focus steal), and the pointerup handler and click suppression are gone. Long-press text selection, previously suppressed by preventDefault, is handled with user-select: none on the tree. Both editors now share the click path and the toolbox code is simpler.
User-visible change (iPad Safari, Monaco alignments to Blocks behaviour):
Deployment to help with testing: https://ipad-toolbox-flyout-followup.review-pxt.pages.dev/
I've tested on Android + Safari, we also re-checked desktop + screen reader. Any other tablet testing much appreciated.
Fixes microsoft/pxt-microbit#6802 (again!)