Is your feature request related to a problem? Please describe.
Issue raised by Claude Sonnet 4.6:
In gizmos.js, addUndoHandler registers a BLOCK_DELETE change listener. When a gizmo-created block is deleted, the listener iterates through all blocks in the DO section to check if the section is now empty. This scan runs once per deleted block — but Blockly fires a BLOCK_DELETE event for every block in a cascade delete, so deleting a parent with many children triggers a full rescan for each one.
For scenes with many blocks this could cause noticeable lag on delete. The fix would be to batch the cleanup using Blockly.Events.setGroup or by deferring the scan with a setTimeout so all deletions in the same event group are processed in one pass.
Is your feature request related to a problem? Please describe.
Issue raised by Claude Sonnet 4.6:
In gizmos.js,
addUndoHandlerregisters aBLOCK_DELETEchange listener. When a gizmo-created block is deleted, the listener iterates through all blocks in the DO section to check if the section is now empty. This scan runs once per deleted block — but Blockly fires aBLOCK_DELETEevent for every block in a cascade delete, so deleting a parent with many children triggers a full rescan for each one.For scenes with many blocks this could cause noticeable lag on delete. The fix would be to batch the cleanup using
Blockly.Events.setGroupor by deferring the scan with asetTimeoutso all deletions in the same event group are processed in one pass.