fix: workspace shifts when deleting a block

[mateusslezinsky]

The basics

• I validated my changes

The details

Resolves

Workspace shifts when deleting a block

Proposed Changes

Instead of resizing the workspace everytime a drag is finished, resizes when a block is deleted.

Reason for Changes

To fix issue #8655.

Test Coverage

Before changes:
before_changes.webm

After changes:
after_changes.webm

[github-actions]

Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:

• You can find tips about contributing to Blockly and how to validate your changes on our developer site.
• All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
• We use conventional commits to make versioning the package easier. Make sure your commit message is in the proper format or learn how to fix it.
• If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the style guide.
  Thank you for opening this PR! A member of the Blockly team will review it soon.

[gonfunko]

Hi, thank you for your interest and resolving this issue and for putting together this PR! While I see from your videos it stops the workspace movement, I think the original call to setResizesEnabled() is still necessary, because it pairs with the corresponding call in startDrag() to reenable workspace resizing after startDrag() disables it for the duration of the drag. In cases where the drag does not result in deletion, resizing would never be reenabled with this change. If you're interested in investigating further, I'd investigate the calls to snapToGrid() and queueRender(); my suspicion is there may be a race condition with block deletion and the things (like snapping and rerendering) we'd do at the end of a normal non-deletion drag which are unnecessary if the block is being deleted but desirable (and could potentially result in adjusting the workspace bounds) in the case where a block is just being moved.

[mateusslezinsky]

Hi, thank you for your interest and resolving this issue and for putting together this PR! While I see from your videos it stops the workspace movement, I think the original call to setResizesEnabled() is still necessary, because it pairs with the corresponding call in startDrag() to reenable workspace resizing after startDrag() disables it for the duration of the drag. In cases where the drag does not result in deletion, resizing would never be reenabled with this change. If you're interested in investigating further, I'd investigate the calls to snapToGrid() and queueRender(); my suspicion is there may be a race condition with block deletion and the things (like snapping and rerendering) we'd do at the end of a normal non-deletion drag which are unnecessary if the block is being deleted but desirable (and could potentially result in adjusting the workspace bounds) in the case where a block is just being moved.

Hello! I have been debugging this issue and it indeed looks like a race condition. The reason for this is because this.block.queueRender() returns a Promise, which is async.

Marking endDrag method from block_drag_strategy as async and then inserting await to queueRender (as await this.block.queueRender()) does fixes the issue however. Should I choose this approach or attempt other fix?

[mateusslezinsky]

After the latest changes, here is how it looks like:
latest.webm