feat: Paste where context menu was opened #9093
Merged
+16
−1
Conversation
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
gonfunko
approved these changes
May 27, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 basics
The details
Resolves
Fixes #9088
Proposed Changes
I updated the
KeyboardShortcutcallback forpasteShortcutto detect whether the initiating event is aPointerEvent, in which case it infers that the callback was called by a context menu item that wraps the callback. (Otherwise, the event would typically be aKeyboardEvent.) If a context menu was used, then the location of thePointerEventis used as the location where the block will be pasted.Reason for Changes
It is commonly expected that if a context menu is used to add a block, then the block will be added where the context menu was opened.
Test Coverage
I have not created any new unit tests for this yet.
Documentation
Probably none needed beyond the code comment I added, although the behavior might be unexpected if someone encounters a different situation where a
KeyboardShortcutcallback sees aPointerEvent, or if a different context menu implementation forwards events differently.Additional Information
There are a few ways we could implement this. I think the above strategy is the least amount of code changes and the only solution that can be done in a single PR, but it makes some assumptions.
Alternatively, we could alter the API of
KeyboardShortcuts to allow explicitly providing a location at which to apply the shortcut's effects, and then update the context menu item wrapper (which is in a different repo) to provide this location. This strategy might be a little more robust, although it's a little weird that aKeyboardShortcutis being used for an action that has a location in the first place and this would just be further committing to that weirdness.Maybe a better alternative would be to refactor the copying and pasting to be public functions outside of the
KeyboardShortcutinterface, so that external code can call them more directly. Notably, there's an existingcopyInternalfunction that could be useful for this, but it's currently private to core Blockly and it doesn't share clipboard data with theKeyboardShortcutversion for some reason. After we make these changes to this repo, we would need to update the external repo to make use of the new API.