Mutator Delete Areas Incorrect After Zoom When Dragging from Flyout

[BeksOmega]

Problem statement

The delete areas are incorrect after zooming, specifically when you drag from the flyout. Delete areas are not recalculated when dragging from the flyout unless there document has been scrolled. They are recalculated when there is an event on the workspace, e.g. a move event, or a delete event. This means that the behavior works correctly when dragging from the workspace to the flyout after zoom, but not the other way around.

Expected Behavior

Delete areas should be calculated correctly, so that blocks are always deleted when dropped on the flyout, and not otherwise.

Actual Behavior

Delete areas are not recalculated, this causes blocks to be deleted when you do not expect it, and to not be deleted when you do expect it.

Steps to Reproduce

1. Add a 'controls_if' block to the playground.
2. Open its mutator and drag a block out of the flyout. This activates updateScreenCalculationsIfScrolled_ before we zoom, so that it won't activate after we zoom.
3. Zoom the workspace in.
4. Drag a block from the flyout, observe how the delete area of the flyout is incorrect.

Stack Traces

Initial drag from flyout that fires the recalculation:

Blockly.WorkspaceSvg.recordDeleteAreas | @ | workspace_svg.js:1188
-- | -- | --
  | Blockly.WorkspaceSvg.updateScreenCalculations_ | @ | workspace_svg.js:717
  | Blockly.WorkspaceSvg.updateScreenCalculationsIfScrolled | @ | workspace_svg.js:776
  | Blockly.Gesture.updateIsDraggingFromFlyout_ | @ | gesture.js:336
  | Blockly.Gesture.updateIsDraggingBlock_ | @ | gesture.js:385
  | Blockly.Gesture.updateIsDragging_ | @ | gesture.js:441
  | Blockly.Gesture.updateFromEvent_ | @ | gesture.js:287
  | Blockly.Gesture.handleMove | @ | gesture.js:542
  | Blockly.TouchGesture.handleMove | @ | touch_gesture.js:181
  | wrapFunc

Operating System and Browser

I am assuming this is not browser specific.

Additional Information

Suggestions:

• Add a call here to update the delete areas even if the document isn't scrolled, but only for mutators.
• Wait until zoom events are a thing, which should fix this automatically (as well as allow a call to be removed from the main workspace).

[RoboErikG]

Is there a reason we shouldn't change updateScreenCalculationsIfScrolled to also check if the zoom has changed?

[BeksOmega]

Is there a reason we shouldn't change updateScreenCalculationsIfScrolled to also check if the zoom has changed?

I got really excited when I saw this, so I gave it a quick test, and sadly it doesn't seem to work because the mutator workspace inherits its scale from the parent workspace, so it's zoom doesn't actually change.

[RoboErikG]

huh...that's probably an oversight if it's inheriting the scale but not the zoom, since those two things should be in sync.

[rachel-fenichel]

iirc mutators are inside the workspace's SVG so they get scale when the workspace SVG's scale is changed. If we also told them to zoom, they would happily zoom themselves, but then the effect would be zoom ^ 2, because the SVG zooms would stack.

(Not saying what we're doing is a good idea, just adding what context I remember)

[BeksOmega]

Could not reproduce. I'm assuming this did get fixed by the viewport change events :D

[BeksOmega]

Hmm I tested this again, and I was able to reproduce it. I might have been testing it incorrectly before. If you drag a new block from the flyout it reproduces. However, if you drag a block already on the workspace toward the flyout, it does not reproduce.