Unable to trigger Toolbox's Block delete style

[zfangqijun]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

When the flyout is open, dragging a Block to the Toolbox does not trigger the Toolbox's Block deletion style(blocklyToolboxDelete)

Reproduction steps

1. Blockly.getMainWorkspace().getFlyout().setAutoClose(false)
2. Open Flyout
3. Drag Block to Toolbox

Stack trace

No response

Screenshots

• Expected, autoClose is true
  

• Unexpected, autoClose is false
  

Browsers

No response

[cpcallen]

Seems at least slightly related to #8413, though possibly different cause.

[johnnesky]

The method updateDragTarget in dragger.ts calls getDragTarget from workspace_svg.ts, which iterates over dragTargetAreas and picks the first one it finds which contains the pointer event. When the flyout is closed, the toolbox is found, but when the flyout is open, the flyout's area overlaps the toolbox area, and the flyout appears to take precedence.

The method getClientRect in flyout_vertical.ts includes this comment, which explains why its drag target area extends beyond the actual flyout's bounds in 3 directions:

    // BIG_NUM is offscreen padding so that blocks dragged beyond the shown
    // flyout area are still deleted.  Must be larger than the largest screen
    // size, but be smaller than half Number.MAX_SAFE_INTEGER (not available on
    // IE).
    const BIG_NUM = 1000000000;

When dragging over these areas, the mouse cursor is correctly updated to indicate that the block will be deleted regardless of whether the toolbox or the flyout is detected as the drag target, but the toolbox's CSS class is only updated if the flyout is closed and the toolbox is detected as the target.

One possible solution would be to make sure that the toolbox takes precedence in getDragTarget when both the toolbox and the flyout are present. The drag target areas are derived from the drag targets found using this query:

    const dragTargets = this.componentManager.getComponents(
      ComponentManager.Capability.DRAG_TARGET,
      true,
    );

Where the 2nd parameter indicates that the DRAG_TARGET components should be sorted in the results, in which case drag targets are sorted by their weight property. I can't find any standard policy for assigning weights to components, but in practice it seems like flyouts, toolboxes, and trashcans are all assigned a weight of 1, whereas the zoom controls are assigned a weight of 2.

From local testing, I can verify that if I assign the weight 1.5 in flyout_base.ts, then the toolbox takes precedence and receives the appropriate CSS class when the mouse is dragging a block over it even when the flyout is present. However, I suspect it would be appropriate to collect the weights in a central location. I'll make an enum or something like that for it.