After autoclosing flyout in vertical grammar, flyout area still is detected as delete area

Expected Behavior

After flyout autocloses, the area under the flyout should be a workspace area, not a delete area. That is, dragging a block onto the area where the flyout used to be should not result in the block being deleted. The horizontal workspace scrollbar should stretch to the left all the way to the categories, at least when the flyout is closed.

Actual Behavior

After autoclosing the flyout, flyout area still is detected as delete area. In addition, before and after the flyout autocloses, the workspace horizontal scrollbar does not stretch to the left into the flyout area.

Steps to Reproduce

1. Set Blockly.VerticalFlyout.prototype.autoClose set to true in flyout_vertical.js
2. Open tests/vertical_playground.html
3. Drag a block out from the flyout
4. Drag the block from the workspace on to the area where the flyout used to be

Operating System and Browser

Mac OS 10.11.6 Chrome 59

[ericrosenbaum]

@rachel-fenichel we’ve now talked this over and decided to support auto-closing flyouts.

@msintov it would help us out if you’re able to describe your bug workarounds, or even better submit a PR. Thanks!

[msintov]

Here are the changes I have made to support an autoclosing flyout (let me know if something seems to be missing):

1. In flyout_vertical.js, set autoClose to true:

Blockly.VerticalFlyout.prototype.autoClose = true;

1. Note that width of the scratchCategoryMenu in css.js is important in the calculations below (by default this is 52px).

2. In toolbox.js, I expose a way to set the width:

Blockly.Toolbox.prototype.setWidth = function(width) {
  this.width = width;
};

1. Note that the desired flyout width is stored in Blockly.VerticalFlyout.prototype.DEFAULT_WIDTH.

2. In Blockly.Toolbox.prototype.init, I calculate Blockly.Toolbox.prototype.width to be the sum of our desired flyout width and the toolbox (52px).

3. At the end of Blockly.hideChaff(), I hide the flyout and also update the delete areas:

        workspace.toolbox_.flyout_.hide();
        workspace.recordDeleteAreas();

1. In flyout_base.js, in Blockly.Flyout.prototype.setVisible, if flyout is set to visible, I set the width of parentToolbox_ to include both the toolbox and flyout width:

    this.parentToolbox_.setWidth(toolboxWidth + this.getWidth());

1. In Blockly.WorkspaceSvg.prototype.recordDeleteAreas , I only take flyout size into account when flyout is visible:

  if (this.getFlyout() && this.getFlyout().isVisible()) {
    this.deleteAreaToolbox_ = this.getFlyout().getClientRect();
  }

1. The biggest hack: in Blockly.WorkspaceSvg.getTopLevelWorkspaceMetrics_, I had to force the toolbox width recognized here to be only the width without the flyout. This enables the user to drag their program closer to the toolbox. Unfortunately I was not able to find a better place to put this fix that didn’t cause other badness like scripts jumping on workspace pan after project load or a newly dragged out block jumping. Probably there is a redraw call that needs to be made after the workspace is loaded instead of hacking it in like this.

    toolboxDimensions.width = 52;