fix: Let old block factory overwrite user defined blocks. #8605
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 #6820
Proposed Changes
Makes a record of all of the reserved block type names that are required by the old block factory workspace on startup, and uses that to determine whether a user-defined block type has a conflicting name, instead of assuming the current definitions in
Blockly.Blocks
is an authoritative proxy for the reserved types.Reason for Changes
The desired behavior is to prevent replacing critical blocks that are used by the block factory, like core Blockly blocks or even block-factory-specific blocks like
factory_base
. The existing strategy is to refuse to overwrite any block type that is currently recognized by the definitions inBlockly.Blocks
, and to support this strategy, whenever the factory defines a user-defined block in this mapping, it always removes the block immediately after adding it so that user-defined block types become available again while critical block types remain reserved. However, there are ways that user-defined block types can "leak" intoBlockly.Blocks
permanently, after which point the block factory will mistake it for a critical block that shouldn't be replaced. For example, if there are already user-defined blocks saved in the block library when the block factory is reloaded or you switch between the factory/exporter tabs, all user-defined blocks will be added toBlockly.Blocks
without being removed, so you're not allowed to make edits to saved blocks after reloading or switching tabs.Test Coverage
There are no tests for the old block factory. It seems to work in my manual testing.
Documentation
N/A
Additional Information
There are at least two publicly hosted copies of the old block factory that ought to be updated:
https://blockly-demo.appspot.com/static/demos/blockfactory/index.html
https://google.github.io/blockly/demos/blockfactory/index.html