During domToWorkspace() child block with FieldDropdown is in workspace's topblock

[ArfyFR]

I updated blockly in a project from
1.20190419.0
to "npm": "blockly": "2.20190722.1"

In order to restore a view, I use
Blockly.Xml.domToWorkspace(this.contentData.content, this.workspace);

In our project we only have one top/root block (with childs) by design.
Some child blocks have FieldDropdown, which are filled with a function like

	new Blockly.FieldDropdown(function createSelectedDataTableField_func() {
		let selectedTables = [];
		...
		return selectedTables;

with FieldDropdown values depending on what is set in the root block.

With Blockly 1.20190419.0 => OK

But with Blockly 2.20190722.1 after domToWorkspace, I faced the following. Traces in console like:

Cannot set the dropdown's value to an unavailable option. Block type: dataset_field_table_column, Field name: FIELD_TABLE, Value: mapchartbycust

In the createSelectedDataTableField_func() call, the child block's getRootBlock() is itself O_o
And the workspace has two+ top blocks, the good one and the child(s). So If I call getRootBlock() to do a
let xyz = rootBlock.getFieldValue('SELECTED_TABLE');
call it won't work anymore.

I had to (bad) hack our code with

	if(rootBlock.type == 'dataset_field_table_column') {
	  rootBlock = rootBlock.workspace.getTopBlocks()[0];
	}

to select the "good" root block.

Later, I get the Blockly.Events.BLOCK_CREATE event, and the child(s) block(s) are (back) to root block childs => OK

Expected behavior

Like before

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome
• Version 76.0.3809.100

[rachel-fenichel]

Thanks for the detailed repro information!

This sounds like a change in the initialization order for fields that broke your blocks. It's not a surprise that blocks are on the workspace when created, and are then attached to the expected parent, but your initialization function must be being called early than it used to be.

@BeksOmega any ideas before I dig in?

[BeksOmega]

@BeksOmega any ideas before I dig in?

The only change I can think of (without digging into it) is that dropdown validators are now called on XML values. This problem doesn't seem to involve validators though, so idk :/

[ArfyFR]

Hi,

My problem is more: in previous version, the root block DURING Blockly.Xml.domToWorkspace() was the good one ;)
(I noticed I wasn't perhaps clear, I use "Dynamic dropdowns" with a function cf doc )

I also don't know why the function to fill the FieldDropdown is called four time for each child block ?
=> to improve ?

Here are some logs :

1. first part, the blocks in the toolbox (in flyout) => ok ignored
2. then the domToWorkspace and the init part (here corrected to switch to real root block id @8H2GG+5_2EcMQ^J[mt=)
3. at last the events part CREATE, MOVE, ...

workflow log.txt

[ArfyFR]

The only change I can think of (without digging into it) is that dropdown validators are now called on XML values. This problem doesn't seem to involve validators though, so idk :/

You wrote the validators are NOW called on dropdown for XML values.
If the "Dynamic dropdowns" isn't (well) called to fill the dropdown choices it leads to the error I faced:
Cannot set the dropdown's value to an unavailable option. Block type: dataset_field_table_column, Field name: FIELD_TABLE, Value: mapchartbycust
In my case, not well called because it is linked to a parent block's field value

Hmmm ...

[ArfyFR]

If other people faced the problem, little "temporary hack" to solve my problem, temporary (during Blockly.Xml.domToWorkspace) bypass the validation for FieldDropdown.

// Save the existing doClassValidation_
let _FieldDropdown_doClassValidation_ = Blockly.FieldDropdown.prototype.doClassValidation_;
// Create a "no validation one"
Blockly.FieldDropdown.prototype.doClassValidation_ = function(newValue) {
  return newValue;
};
Blockly.Xml.domToWorkspace(xml, workspace);
// restore the saved doClassValidation_
Blockly.FieldDropdown.prototype.doClassValidation_ = _FieldDropdown_doClassValidation_;

[RoboErikG]

Possibly fixed. @samelhusseini to confirm.

[samelhusseini]

Yes, we are no longer calling the validation method in the constructor which was the cause of this issue. However, I've also looked into optimizing the number of times we call the dynamic function generator here: #3036