Check for duplicates
Description
This is a very unlikely corner case in a legacy component, but I wanted to write it up in case someone else encounters it. TL;DR: domToBlockHeadless doesn't throw on failed parentConnection.connect and it should.
Basically, if an input block cannot connect to its parent during the load, the offending block gets stuck in a weird uninitialized state.
To be fair, you shouldn't do things that cause this (change the block definition in a way that affects existing programs), but it can happen by mistake, and one would hope for the process to at least fail gracefully. (The JSON system fails and throw an erorr, which is perfectly OK.)
Why this happens: the domToBlockInternal calls domToBlockHeadless on a node and recursively on its children, each of which tries to connect to its parent (but if the connection doesn't succeed, nothing happens). Then it initializes the resulting block and all its descendants. If a block doesn't get connected during the first step, it's not a descendant, and therefore doesn't get initialized. Ghost block!
Considering Blockly's generally strict approach to desertialization, the expected behavior would be an error on the failed connect (as in JSON), which would help by making the debugging less confusing ;-).
Reproduction steps
- Save a program with connected input blocks to XML.
- Adjust the connection check on some of the the blocks so that they cannot connect anymore.
- Load the program to workspace.
- The workspace is in a weird state. Some input blocks are not visible, but they are present in a 'ghost' state.
- If you save and reload the workspace, everything is ok once again. The unconnectable blocks are present and normal (disconnected, of course)
Stack trace
Screenshots
No response
Browsers
No response
Check for duplicates
Description
This is a very unlikely corner case in a legacy component, but I wanted to write it up in case someone else encounters it. TL;DR:
domToBlockHeadlessdoesn't throw on failedparentConnection.connectand it should.Basically, if an input block cannot connect to its parent during the load, the offending block gets stuck in a weird uninitialized state.
To be fair, you shouldn't do things that cause this (change the block definition in a way that affects existing programs), but it can happen by mistake, and one would hope for the process to at least fail gracefully. (The JSON system fails and throw an erorr, which is perfectly OK.)
Why this happens: the
domToBlockInternalcallsdomToBlockHeadlesson a node and recursively on its children, each of which tries to connect to its parent (but if the connection doesn't succeed, nothing happens). Then it initializes the resulting block and all its descendants. If a block doesn't get connected during the first step, it's not a descendant, and therefore doesn't get initialized. Ghost block!Considering Blockly's generally strict approach to desertialization, the expected behavior would be an error on the failed connect (as in JSON), which would help by making the debugging less confusing ;-).
Reproduction steps
Stack trace
Screenshots
No response
Browsers
No response