Cannot read properties of undefined (reading 'getBubbleSize')

[Bart Butenaers]

Hi everybody,

We released yesterday a new version of the Blockly integration for Node-RED, in which we migrated from Blockly version 6.x to 10.x.

However today a bug was reported by one of our users.  As soon as procedure blocks are being used in the workspace:


Then some of our functionality starts failing due to this kind of errors:

Uncaught TypeError: Cannot read properties of undefined (reading 'getBubbleSize') ( xml.ts:194)
    at blockToDom$$module$build$src$core$xml (xml.ts:194:26)
    at blockToDomWithXY$$module$build$src$core$xml (xml.ts:106:19)
    at Object.workspaceToDom$$module$build$src$core$xml [as workspaceToDom] (xml.ts:54:25)
    at Object.open (<anonymous>:819:51)
    at n (red.min.js?v=:19:44660)
    at red.min.js?v=:19:45794

The error occurs here in the blockToDom function:


For this object:

Does this ring a bell to somebody?  

I haven't changed anything in my toolbox files, but perhaps I should (somehow)?

Thanks!!

Bart

[Maribeth Moffatt]

Do you override getCommentText in your blocks or specifically in the procedure blocks? Or do anything custom that might be related to comments and/or procedure blocks?

In block.getCommentText in core we also use `getIcon` to get the comment icon, so if that were returning undefined (like it is in your screenshot line), then presumably `commentText` should also be null. Can you also check what is the value of `IconType.COMMENT`? Thanks! I'm sure we can get to the bottom of this.

Maribeth

[Bart Butenaers]

Hi Maribeth,

Thanks for joining!!

I can't remember that I have overridden anything about procedures.  Did a quick search and can't find anything about it in my code....

Hopefully you can find any useful information in the following screenshot:

And this one:

[Maribeth Moffatt]

Just noting here that I'm following up with this with the node-red-contrib-blockly repo offline and will post here with any updates if we can figure out the root cause of this issue. If anyone else has seen something like this, do let us know! Thanks,

Maribeth

[Maribeth Moffatt]

I've filed https://github.com/google/blockly/issues/7610 to track this possible issue. I'm hoping we can dedicate time to look more into it soon. In the meantime, if anyone else has experienced this problem, if you could post your details in the issue, that would be very helpful! Thanks,

Maribeth

[Bart Butenaers]

Hi Maribeth,

Thanks for all your efforts to try to solve this!!

Bart

[Zoey Li]

Hi Bart,

I took a look at your github repo and I noticed that when configurations change you are loading a new copy of Blockly here:
https://github.com/bartbutenaers/node-red-contrib-blockly/blob/master/blockly.html#L975

Going further you are serializing a workspace from the old Blockly instance with the new Blockly instance here:
https://github.com/bartbutenaers/node-red-contrib-blockly/blob/master/blockly.html#L228

While this code was working before, I think by doing so it will mess up some assumptions in the blockly code base, such as (instanceof would fail when comparing an old instance against a new class).
I would suggest you serializing the workspace as XML before destructing the old Blockly instance or attempt to not recreate the Blockly instance.

Cheers
Zoey

[Bart Butenaers]

Hi Zoey,

What a pity that you had to spend your valuable time on analyzing my custom code, to find out it was not a Blockly issue.  But your assistance is highly appreciated!

Just to make sure I understand it correctly.  

About the quote "serializing the workspace as XML before destructing the old Blockly instance".

Currently it works like this:

var dom = Blockly.Xml.workspaceToDom(node.workspace);
var originalXml = Blockly.Xml.domToPrettyText(dom);
createWorkspace(node, originalXml);

function createWorkspace(node, workspaceXml) {

   ...
   if (node.workspace) {
      node.workspace.dispose();
      node.workspace = null;
   }  

   ...

   node.workspace = Blockly.inject('blocklyDiv', { ... });

   ...

}

So I serialize the old workspace (to originalXml) before I destruct the old workspace.  

Is there anything else that I should destruct, to (hopefully) make sure the old instance isn't compared to a new class?

Thanks!

Bart

[Zoey Li]

No worries!

Just to add more clarity, loadResourcesFromServer is called multiple times, and each time a new Blockly instance is created from that call.

So this is what happens:

loadResourcesFromServer is called and Blockly instance A is created
A creates a workspace W using createWorkspace
Later, loadResourcesFromServer is called again and Blockly instance B is created
B is used to serialize W (that was created by A) into XML using workspaceToDom and this call fails.

Instead, you can use the first Blockly instance A to serialize W before loading the second Blockly instance B.  An example of this is
https://github.com/bartbutenaers/node-red-contrib-blockly/pull/116

Longer term, perhaps it's possible to explore how to avoid loading Blockly more than once if its already loaded.

--
You received this message because you are subscribed to a topic in the Google Groups "Blockly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blockly/Rc5WiS8J1kc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/e2cf4a49-ac4b-410e-99ad-4e9760fdfd7bn%40googlegroups.com.

[Bart Butenaers]

Hi Zoey,

That explanation is very clear!!! 

Nice catch! It would have taken me ages to find the root cause of this one...

And thank you soooo much for your pull-request!!  I will test it this weekend.  Once ok for me I pass it to Simon Walters for more advanced testing.  He is a retired engineer from the UK, that has promoted himself sometime ago as head of the QA departement of my blockly node for Node-RED ;-)  What an international cooperation.  This is one of those days that I love the concept of open-source development...

Will get back here afterwards

[Bart Butenaers]

Hi Zoey, Maribeth,

Simon has tested all day and couldn't find any issues anymore.  

Thanks again for the awesome support!!

Greetings from a rainy Belgium,

Bart