[X] I have searched for similar issues before opening a new one.
Description
In https://github.com/google/blockly/pull/8575 I noticed that the undo history isn't recorded correctly when a block's inputs are created or destroyed in response to a field validator. If a child block was attached to an input when the input is being destroyed, the block will become detached, which is recorded as a BlockMove event, but this event is not grouped with the BlockChange that caused it. This can cause problems when undoing, because the creating the input separately from moving the detached child block is likely to "bump" the child otherwise. If the child block gets bumped while undoing, that records a BlockMove event that can unintentionally erase any remaining the redo history.
The following block types are known to be affected:
lists_getIndex
lists_setIndex
lists_getSublist
text_getSubstring
Whether or not we want people to be making changes to the workspace in field validators is an interesting question, but the fact remains that it's already happening, in the blockly core library no less.
Drag a lists_getIndex and a math_number block into the workspace.
Attach the number block to the input connection.
Edit the dropdown field that says "#", changing it to "first" or "last". The number block will become detached, but remain in place overlapping the lists_getIndex block. A BlockMove event with a group id will have been fired, followed by a BlockChange event without any group id.
Undo once. This will recreate the input connection, but won't attach the child block to it. Instead, the child block will get bumped.
Check for duplicates
Description
In https://github.com/google/blockly/pull/8575 I noticed that the undo history isn't recorded correctly when a block's inputs are created or destroyed in response to a field validator. If a child block was attached to an input when the input is being destroyed, the block will become detached, which is recorded as a
BlockMoveevent, but this event is not grouped with theBlockChangethat caused it. This can cause problems when undoing, because the creating the input separately from moving the detached child block is likely to "bump" the child otherwise. If the child block gets bumped while undoing, that records a BlockMove event that can unintentionally erase any remaining the redo history.The following block types are known to be affected:
lists_getIndexlists_setIndexlists_getSublisttext_getSubstringWhether or not we want people to be making changes to the workspace in field validators is an interesting question, but the fact remains that it's already happening, in the blockly core library no less.
See also: https://github.com/google/blockly/issues/6456
Reproduction steps
lists_getIndexand amath_numberblock into the workspace.lists_getIndexblock. A BlockMove event with a group id will have been fired, followed by a BlockChange event without any group id.Screenshots
https://github.com/user-attachments/assets/25acb00b-ba20-4408-aa5d-6fc1ab4a7d10