Scratch-gui: Doesn't work the block go to position.

[jpnykw]

Expected Behavior

Doesn't work the block go to x:() y:().

Actual Behavior

When all costumes be delete.

until old version it is working.

Steps to Reproduce

1. go to costumes and delete all there's.
2. use go to block set any position.
3. draw dot by pen.

Operating System and Browser

Chrome 71 on Windows 10

[joker314]

Nice! This looks like an issue with the bounding box calculation which the go to x: y: block requests.

• go to x: y: invokes setXY of rendered-target
• setXY requests fenced position of drawable from scratch-render
• getFencedPositionOfDrawable in scratch-render

The bottom link probably has the bug. It gets the bounding box, by invoking more methods, and I assume it struggles to find the bounding box of an empty costume, and hence it is prevented from moving past (0,0)

[thisandagain]

/cc @kchadha @cwillisf

[thisandagain]

/cc @ktbee

[ktbee]

Thanks for reporting this @JPNYKW and for taking a look @joker314!

After some more digging, we found the root cause has to do with how scratch-paint handles empty costumes and scratch-render incorrectly setting rotationCenter because of it. Currently scratch-paint creates a 1x1 empty svg for empty costumes, whereas in Scratch 2 the editor created a 0x0 svg for an empty costume. We have logic to correctly set rotationCenter for empty skins with an expected size of 0x0, but because the size is 1x1, we're not using that logic. This means Scratch uses the incorrect center of the costume and doesn't allow the pen tool to draw on the full width and height of the stage.

Hope this helps clear things up, I'm working on a fix for scratch-paint now.

[ktbee]

On second thought, it looks like scratch-paint actually generates a 0x0 svg correctly when you delete the costume. Instead I found that the svg's width and height are incorrectly increase by one in scratch-svg-renderer:

https://github.com/LLK/scratch-svg-renderer/blob/develop/src/svg-renderer.js#L311-L312

@cwillisf I noticed you added this code and the comment explaining the need for it, though I didn't fully understand the circumstances where it's useful. Are there certain projects that need the bbox enlarged? I was picturing preserving the bbox width or height if it's zero with code to this effect:

const width = bbox.width === 0 ? 0 : bbox.width + (halfStrokeWidth * 2);
const height = bbox.height === 0 ? 0 : bbox.height + (halfStrokeWidth * 2);

and I'm wondering if this will break the projects that this code was initially intended to fix.

[cwillisf]

@ktbee yep - I think your suggestion makes a lot of sense.

The code to add stroke width to the bounding box originally came from LLK/scratch-render#179 as a fix for LLK/scratch-render#175. Since the issue here is about "empty" SVGs they can't be affected by LLK/scratch-render#175 so it makes sense to exempt them from the fix.

We plan to eventually go back and fix this by calculating real bounds, including stuff like checking whether or not a stroke width takes a path off the edge of the stage, but for now I think checking against a zero-width or zero-height bounding box is a good idea.