Cannot copy a shadow block

[rachel-fenichel]

Thanks for the explanation and demo, that makes a lot of sense. I can't help but favour the plugin's behaviour of turning a shadow block into a real block on edit - since that shows intent from the user to make something concrete. Are there situations or applications in which this wouldn't make sense, or previous discussions I can refer back to learn about the competing needs?

There are downstream consequences of this behaviour on copy and paste, which don't make up with my expectations. I would have assumed you'd be able to copy and paste the contents of an oval, like the text in a "write with shadow" block

I would naively argue that these blocks should be real, and draggable, and copyable. If they are not, then we definitely need some user feedback when they try to copy a block, because currently copy will silently fail and you'll end up surprised by pasting the last thing in the copy buffer.

Originally posted by @kmcnaught in #132

[rachel-fenichel]

Shadow blocks can't be copied, likely due to checks for isDeletable and isMovable in blockCopyPreconditionFn in navigation_controller.ts.

It should be possible to copy them, since users can't tell which blocks are shadows and which aren't in Zelos. (I think it should also be possible to copy them in Geras). However, the block needs to be converted from a shadow block to a real block either on copy or on paste.

[kmcnaught]

I think there are also some residual splicing behaviours that need discussion.

Here's an example video showing that if your curosr is on an oval variable block, and you insert a [statement block that contains an oval child], then the new block splices in and then gets spat out to the workspace, effectively 'stealing' the variable block.

I am unable to replicate this with mouse behaviour, because the insertion is not valid, so the mouse drag doesn't allow it. It's like the splicing is being attempted in the wrong direction, so the downstream connection is made, and then the upstream connection is rejected.

(Not sure if new bug or just additional example of how the splicing behaviour we've discussed manifests - feel free to move to a new issue)

[maribethb]

Note that with RaspberryPiFoundation/blockly-keyboard-experimentation#501 this behavior should be implemented in core

[rachel-fenichel]

"Should be" meaning new code needs to be added in core, or meaning that the only remaining work is verification?

[maribethb]

needs to be added in core

[cpcallen]

I've put together a working proof-of-concept of a change a developer could make to enable copying shadow blocks.

I've also filed #9098 to track a better long-term fix for this issue, and am closing this issue in favour of that one.