Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: disposing of a workspace that has overwritten shadows #6424

Merged
merged 5 commits into from
Sep 26, 2022

Conversation

BeksOmega
Copy link
Collaborator

The basics

  • I branched from develop
  • My pull request is against develop
  • My code follows the style guide
  • I ran npm run format and npm run lint

The details

Resolves

Part of #6358

Proposed Changes

Change where we set block.disposed to true. I audited all of the places where disposed is referenced, and I don't think this will break anything. But let's be honest, it probably will break something.

Behavior Before Change

If you disposed of a workspace that had an overwritten shadow block in it, the workspace would throw an error. See #6358 (comment)

No end-user-facing change in behavior.

Behavior After Change

No Error!

No end-user-facing change in behavior.

Reason for Changes

Errors are sad =(

Test Coverage

Manually tested that disposing of a workspace with the following blocks in it did not cause an error to be thrown:

{
  "blocks": {
    "languageVersion": 0,
    "blocks": [
      {
        "type": "math_single",
        "id": "f#E]:l@J;BJ;N(?;KQ5T",
        "x": 138,
        "y": 138,
        "fields": {
          "OP": "ROOT"
        },
        "inputs": {
          "NUM": {
            "shadow": {
              "type": "math_number",
              "id": "wr:jE3$@EZ(/{pNSq92C",
              "fields": {
                "NUM": 9
              }
            },
            "block": {
              "type": "math_number",
              "id": "5A]oz4Gd$y]!BUkH/i~@",
              "fields": {
                "NUM": 123
              }
            }
          }
        }
      }
    ]
  }
}

Documentation

N/A

Additional Information

Caused by https://github.com/google/blockly/pull/6300/files#diff-dd85563e074ebb74e4c34eee01568971430f3cb7a6b846feef8044ad8d5dcd61L566

The issue is that workspace used to be set to null before the blocks were disposed, so that would properly cause createShadowBlock_ to short circuit. But because createShadowBlock_ was now looking at disposed it wasn't short circuiting, because disposed was set after the blocks were disposed.

@BeksOmega
Copy link
Collaborator Author

I think it might actually be safest to add an internal disposing property, and replace all the places where we used to be checking block.workspace == null with that, so that we know the new behavior is 100% consistent.

But on the other hand, I hate using state to define functional logic.

So Imma sleep on it.

core/block.ts Outdated
@@ -356,7 +357,6 @@ export class Block implements IASTNodeLocation, IDeletable {
}
} finally {
eventUtils.enable();
this.disposed = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know where the exception this try/catch is wrapping is thrown? Do we still need this here in case it throws prior to disposed being set to true in the try?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha no. Back in 2016 a contributor just wrapped everything between an Events.disable() and an Events.enable() in a try...finally to make sure that events were always re-enabled: #348

tests/mocha/event_test.js Show resolved Hide resolved
core/block.ts Outdated Show resolved Hide resolved
@BeksOmega BeksOmega merged commit f2e408b into google:develop Sep 26, 2022
@BeksOmega BeksOmega deleted the fix/workspace-disposing branch October 4, 2022 18:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants