Blockly: Mutators of shadow block lists_create_with creates extra shadow block

[pmwthunkable]

Problem statement

TODO...

Expected Behavior

An empty socket should appear where the new socket was created.

Actual Behavior

Steps to Reproduce

Add this to the blockly playground. Add a mutator between 2 and 3. A 3 shadow block appears both in the new socket and on the workspace

<xml xmlns="http://www.w3.org/1999/xhtml">
  <block type="lists_isEmpty" id="lUo%hD1:H)4+qIGwduxZ" x="113" y="213">
    <value name="VALUE">
      <shadow type="lists_create_with" id="McTQO_+6S`Iv,ZCC%$$g">
        <mutation items="3"></mutation>
        <value name="ADD0">
          <shadow type="math_number" id="7eym=to%}T8dnGV^zCix">
            <field name="NUM">1</field>
          </shadow>
        </value>
        <value name="ADD1">
          <shadow type="math_number" id="sVBui$corF3h0`9!e6jz">
            <field name="NUM">2</field>
          </shadow>
        </value>
        <value name="ADD2">
          <shadow type="math_number" id="q+gA9N/,:Xk?eo.:7R3N">
            <field name="NUM">3</field>
          </shadow>
        </value>
      </shadow>
    </value>
  </block>
</xml>

1. Start by..
2. Next, do..

Stack Traces

Replace with error stack trace.

None

Operating System and Browser

Additional Information

[seldomU]

Also, when one of those inputs is removed, the connected shadow block stays on the canvas and it can't be dragged from its position.

[rachel-fenichel]

Usually this means that there's a shadow DOM on an input that we're trying to clear out, so it just keeps respawning. The solution is usually to clear out the shadow DOM, then manipulate (add, remove, whatever) the inputs, then add back the shadow DOM.

[RoboErikG]

This is a problem with the compose method for list_create_with. The mutator was written before we had shadow blocks and the logic was never updated to deal with them, so they get disconnected and moved around like normal blocks which can leave them orphaned.

That method needs to be updated to support shadow blocks in a sane way, which probably should be to reorder the shadows if inputs are reordered, but to just delete them and forget about the shadow entirely if the input is removed.

[seldomU]

In compose() I dispose the blocks that were disconnected and are shadow blocks. That seems to work well.

[seldomU]

Actually, there's still a problem with that method: when the mutator is used to rearrange inputs. When a stack item is taken from the buttom and inserted above, any shadow block connected to the corresponding input is lost.

[pengliheng]

so what mean by ADD0, ADD1, ADD2

Ignoring non-existent input ADD0 in block lists_create_with