Disabled procedure blocks are re-enabled after a change

[maribethb]

Check for duplicates

• I have searched for similar issues before opening a new one.

Component

plugins/block-shareable-procedures

Description

If a user disables procedure call blocks, they'll be re-enabled automatically when the matching definition block is modified (e.g. renamed or parameters added). This is undesirable.

Reproduction steps

1. Open the block-shareable-procedures test page
2. Drag a new procedure definition onto one of the workspaces
3. Drag a call block for this procedure onto either workspace (doesn't matter which one)
4. Disable the call block
5. Rename the procedure in the definition block
6. Observe how the block was re-enabled

Stack trace

No response

Screenshots

Oct-25-2023.11-40-18.mp4

[maribethb]

@johnnesky any interest in looking at this one next?

[johnnesky]

Sure!

[johnnesky]

Intended behavior: When core procedures are disabled, the enabled state of call blocks is recorded and the call blocks are forcibly disabled. When core procedures are enabled, call blocks are restored to their recorded state. (This recorded state is not serialized so this breaks on reload but that's not the problem being tracked here.)

Bug: In the shareable procedure plugin, whenever any change is made to the procedure, the above actions are executed depending on whether the procedure is currently enabled, but if the procedure remains in the enabled state, then the call block will be "restored" to a state that was never properly recorded in the first place. We only really want to execute these actions when there is an actual change to the value of the enabled state of the procedure definition, rather than when there is any change to the definition.

Currently looking for a solution.

[clementcontet]

Hi, I'm not sure if it is 100% related, but when you serialize and then deserialize a disabled procedure block, it gets automatically re-enabled.

[johnnesky]

google/blockly#7958 has been merged into blockly. When blockly v11.0.0 is published, then this procedure plugin can be updated to use the same system.

[maribethb]

@johnnesky if you want to fix this next, you can work off the rc/v11 branch of samples and submit the fix there. You can locally link blockly for testing and submit the change to that branch. When we release v11 of core we'll also release that branch so the fix can be published asap.

[BeksOmega]

You can locally link blockly for testing and submit the change to that branch.

With the migration to the new exports format in the package.json I've found linking to be a bit weird. The steps I've found to work are:

1. npm run package in core.
2. cd dist
3. npm link
4. cd into your samples plugin (in this case shareable procedures)
5. npm link blockly npm link blockly --force
6. cd ../../ up to the root level of samples.
7. npm ci -> This relinks to the local versions of dev tools and test blocks, without unlinking the local blockly.
8. cd back into your plugin.
9. npm ls to check that packages are all properly linked.