Update to Blockly 12

[mjgallag]

No description provided.

[TannerGabriel]

I tested this with the Blockly demo project and it worked fine with the JavaScript variant.

When using the TypeScript example, I encountered an import error similar to issue #38, but that’s not really relevant to this PR.

[TannerGabriel]

After using the PR for additional testing with the TypeScript version, I encountered an issue when opening the toolbar after creating a function with parameters. This also occurs in the JavaScript version.

Steps to Reproduce

1. Create a Blockly demo application (npx @blockly/create-package app hello-world)
2. Add the plugin
3. Create a function and add parameters
4. Reopen the toolbar

After some debugging, I found the issue originates from the procedures_callreturn block definition. I resolved it by implementing the saveExtraState and loadExtraState methods (newer JSON-based methods replacing XML) with the same logic as mutationToDom and domToMutation.

Fix

saveExtraState() {
    const params = [];
    for (let i = 0; this.getInput('ARG' + i); i++) {
      const input = this.getInput('ARG' + i);
      const field = input.fieldRow[0];
      params.push(field.getText());
    }
    return {
      name: this.getFieldValue('PROCNAME'),
      params,
    };
  },
  loadExtraState: function(state) {
    const name = state['name']
    this.setFieldValue(name, 'PROCNAME');
    this.arguments_ = []
    state.params.forEach(argument => {
      this.arguments_.push(argument)
    });

    this.setProcedureParameters(this.arguments_, null, true);
  },

Screencast.from.2025-08-09.17-57-23.webm

[TannerGabriel]

It might generally be beneficial to add the JSON functions to all blocks. Let me know your opinion here @mjgallag

[mjgallag]

@mjgallag I'm very new to Blockly at the moment so still trying to wrap my head around what makes sense in a plugin and what doesn't. @mark-friedman might have a better sense.

[mark-friedman]

I might be worth trying to figure out what, exactly, is going wrong with the XML-based mutation functions. AFAIK, that hasn't been a problem before, so maybe there is something going on with Blockly 12 (or 11) that is causing this and it would be worth our knowing what that is.

Part of the context here, @TannerGabriel, is that we are also in the process of updating MIT App Inventor to Blockly 11 (and later, 12) and if we need to alter all of its blocks' mutation functions from the XML-based ones to JSON-based ones, it would be really nice to know asap.

[TannerGabriel]

Fully agree here. The problem doesn't seem to happen in Blockly V11 and according to the documentation a missing saveExtraVars or loadExtraVars function should normally result in calling domToMutation and mutationToDom. As far as I can tell right now, the problem is only happening for dynamically added blocks like the procedures_callreturn and procedures_callnoreturn. Do you have any further inside regarding this @mark-friedman?

While testing, I also found another issue that occurs in both Blockly V11 and V12. It throws an error when trying to add a second variable to the local_declaration_statement block.

Steps:

1. Run npm run start
2. Add local_declaration_statement block
3. Add a second variable inside of the mutator

Cannot read properties of null (reading 'setAttribute')
TypeError: Cannot read properties of null (reading 'setAttribute')
    at Drawer$$module$build$src$core$renderers$geras$drawer.layoutField_ (webpack-internal:///./node_modules/blockly/blockly_compressed.js:1264:476)
    at Drawer$$module$build$src$core$renderers$geras$drawer.drawInternals_ (webpack-internal:///./node_modules/blockly/blockly_compressed.js:1264:76)
    at Drawer$$module$build$src$core$renderers$geras$drawer.draw (webpack-internal:///./node_modules/blockly/blockly_compressed.js:1666:754)
    at Renderer$$module$build$src$core$renderers$geras$renderer.render (webpack-internal:///./node_modules/blockly/blockly_compressed.js:1299:502)
    at BlockSvg$$module$build$src$core$block_svg.renderEfficiently (webpack-internal:///./node_modules/blockly/blockly_compressed.js:1060:491)
    at renderBlock$$module$build$src$core$render_management (webpack-internal:///./node_modules/blockly/blockly_compressed.js:164:236)
    at doRenders$$module$build$src$core$render_management (webpack-internal:///./node_modules/blockly/blockly_compressed.js:161:348)
    at triggerQueuedRenders$$module$build$src$core$render_management (webpack-internal:///./node_modules/blockly/blockly_compressed.js:159:167)
    at BlockSvg$$module$build$src$core$block_svg.render (webpack-internal:///./node_modules/blockly/blockly_compressed.js:1060:240)
    at BlockSvg$$module$build$src$core$block_svg.updateDeclarationInputs_ (webpack-internal:///./src/blocks/lexical-variables.js:350:12)

After some debugging, I was able to fix the issue by using the input getters and setters instead of directly manipulating inputList and by replacing initSvg() and render() with queueRender(), but I'm not sure yet why this would be necessary.

[TannerGabriel]

We should probably also add additional unit tests that interact with the mutations and test these scenarios for future version updates.

[TannerGabriel]

Any news on how to continue with the update?

[mark-friedman]

Any news on how to continue with the update?

For one I would suggest adding the additional unit tests that interact with the mutations that you suggested.

@mjgallag Are you seeing the problem that @TannerGabriel pointed out above where the plugin throws an error when trying to add a second variable to the local_declaration_statement block?

[TannerGabriel]

The test cases I mentioned involve UI interactions, like using the toolbox and applying mutations. Do you plan to cover these with browser tests (e.g. Playwright), or simulate them with the current test setup?

[mjgallag]

@mark-friedman if I run npm install && npm start I get the same error seen in @TannerGabriel's video above when I click on Functions. I only get it in the Blockly 12 branch (this PR), not in the Blockly 11 branch or the main branch (Blockly 10). Will be interesting to see if we get this same error in App Inventor with Blockly 12 but we haven't gotten that far yet.

[mark-friedman]

The test cases I mentioned involve UI interactions, like using the toolbox and applying mutations. Do you plan to cover these with browser tests (e.g. Playwright), or simulate them with the current test setup?

Ah, so they actually require UI interactions? I should have inferred that from your previous comments. This is quite odd and suggests some kind of timing issue that queueRender fixes. So, @mjgallag I would suggest making the queueRender fix that @TannerGabriel mentioned and making sure that it works with Blockly 11 as well as Blockly 12.

I would suggest that for now, let's not bother with browser tests for this.

[mjgallag]

@mark-friedman ah, sorry wrong bug. @TannerGabriel thanks for testing, I can reproduce adding 2nd variable to local_declaration_statement issue in Blockly 11 branch here and in App Inventor's Blockly 11 branch. If you wouldn't mind could you submit a pull request with your proprosed fix mentioned above with a base of https://github.com/mit-cml/blockly-plugins/tree/update-to-blockly-11? Thanks!

[TannerGabriel]

@mjgallag Sure, I’ve opened PR (#76) with the proposed fix. While working on it, I also ran into another issue with getter/setter warning messages, which I also addressed in the same PR.

Let me know if you’d like any additional help with the V11/V12 updates.

[mark-friedman]

@mjgallag is this still just a draft or is it ready for review?

[mjgallag]

@mark-friedman draft, I have not worked on #68 (comment) yet.