Scratch-gui: Changing sprite of a "(attribute) of (sprite)" in block palette rearranges blocks in the workspace (sometimes)

[towerofnix]

Expected Behavior

The "(attribute) of (sprite)" block does not destroy your project.

Actual Behavior

It does.

Case in point:

Every script is positioned at (0, 0).

Zip file of this project attached (see "Battle Controller" sprite): Untitled-297.zip

Steps to Reproduce

I can't reliably repro this, unfortunately, but it's happened to me several times while developing that large project. This only ever occurs immediately after I change the sprite selected in the dropdown menu. It's a huge pain and always causes either lost progress (restoring from a page reload) or rearranging all the scripts back to where they're supposed to be.

Operating System and Browser

Firefox 65.0b11, Linux (Debian).

[towerofnix]

I'm not sure if it's relevant or not (absolutely could be a red herring), but I think I've always been zoomed in whenever the wonkiness happens. (As in scratch-blocks zoom, not browser zoom; I always work slightly zoomed in while using Scratch 3.0.)

[thisandagain]

/cc @kchadha @ktbee @picklesrus

[kchadha]

@towerofnix Could you explain how this issue is related to the(attribute) of (sprite) block? Are you seeing this issue only in workspaces that have that block? What browser(s) are you seeing this issue in?

[towerofnix]

@kchadha Sorry for the lack of a consistent repro case. I'm having trouble reproducing this myself, even following my earlier notes (i.e. the comments here) and working in the same project.

Yes, it's tied to the "of" block. See my notes in "Steps to Reproduce":

This only ever occurs immediately after I change the sprite selected in the dropdown menu.

Just the same, the browser I used is noted.

I believe that selecting an option from the sprite menu is causing the workspace to reload, which is presumably capable of causing a mess with this, although I cannot repro this lately. Or perhaps it's not a workspace reload; it needs more investigation.

Here's what I can reliably reproduce while working inside https://scratch.mit.edu/projects/284710366/editor/:

• Changing the selected sprite in the "of" block's menu causes a noticeable amount of lag (unresponsive editor time). (Is this because there are a lot of blocks in the workspace; or, maybe more likely, is it because there's a lot of sprite-local variables? Needs more testing.)

• When the workspace is zoomed in (not when it is at normal ("=" button) scale or zoomed out), changing the selected sprite also changes the scroll position. It almost looks like it's changing the workspace metrics to whatever the currently-saved scrollX/scrollY is, but I'm not sure about that. (Edit: see also #4542.)

Neither of those are obviously connected to the strange screenshot I got there. I honestly wonder if they're totally unrelated issues... but, hopefully they give you a picture of the sort of experimenting I'm (unsuccessfully) doing to try to repro this.

[kchadha]

Yes, it's tied to the "of" block. See my notes in "Steps to Reproduce":

This only ever occurs immediately after I change the sprite selected in the dropdown menu.

Oh I see, sorry! I didn't realize that was referring to the sensing_of block and mistakenly thought you were referring to switching between sprites.

Thank you for the extra information!

[towerofnix]

I didn't realize that was referring to the sensing_of block and mistakenly thought you were referring to switching between sprites.

Yeah, sorry -- I noticed my original post might've been misinterpreted when I was re-explaining it...glad to clear that up!

[towerofnix]

Someone else saw this happened in their project, so we can at least be sure it's not limited to my one project: https://scratch.mit.edu/discuss/topic/344142/

(See also https://github.com/LLK/scratch-gui/pull/4613#issuecomment-472255942 which discusses implementation of fixing this issue.)

[griffpatch]

I have had this happen to me too...
It was linked to me pressing undo though?
Perhaps after adding one of those sensing blocks? But I can't remember...
It was very annoying ;). I pressed undo or redo (can't remember) and all my
scripts moved to the top left and would not return no matter what undo redo
I then pressed. Sorry I have no repo

On Fri, 15 Mar 2019, 14:43 Florrie, [e-mail] wrote:

Someone else saw this happened in their project, so we can at least be
sure it's not limited to my one project:
https://scratch.mit.edu/discuss/topic/344142/

(See also #4613 (comment)
https://github.com/LLK/scratch-gui/pull/4613#issuecomment-472255942
which discusses implementation of fixing this issue.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LLK/scratch-gui/issues/4400#issuecomment-473312890,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGbNvnvFdCKYCiSab0cXkT81tz0guwN1ks5vW7F6gaJpZM4aJs_f
.

[BryceLTaylor]

It seems that I can reproduce this regularly on Chrome on Mac by changing the Sprite in that block while the block is still in the Blocks Palette. Often you must change it more than once.

[towerofnix]

@BryceLTaylor Thank you! I can repro it that way as well (Firefox). It only happens when I change the option in the flyout, not if the block is dragged into the workspace.

[kchadha]

@BryceLTaylor thanks for the repro! I think it'll really help with investigating what's breaking about the block coordinates!

[LukeSchlangen]

Since this is impacting my students pretty regularly, I would be interested in digging into this. I spent two hours digging in, but I didn't have much luck. I think my lack of understanding around how the state of the project blocks are set (specifically the x, y coordinates), is making it hard for me to find the root.

Is there a particular dispatch or listener that we think is responsible for this behavior?

It seems like it might be tied to the UPDATE_TOOLBOX redux action. The action seems to fire twice every time a new selection is made, and the first attempt (on the second selection) is the one that seems to be setting all of the offsets to 0, 0.

The only thing that seems unique about this block is that it is the only block with multiple dropdowns.

I can't seem to find where the positions are changed? It's definitely that the x and y position of the blocks are being set to x: 0 and y: 0, so I'm wondering if there are some defaults somewhere?

Is it possible that this is a https://github.com/LLK/scratch-vm bug instead?

I'd love to take this on if it seems like something someone outside the core team might have a chance with!

[towerofnix]

@LukeSchlangen You'll want to have a look at the discussion/descriptions of the PRs I made back in March (#4613 and the associated ones) for details on how the "of" block is peculiar. The TL;DR is that the workspace is reloaded whenever the sprite menu is changed, to reflect the updated default option in the property menu.

I'm definitely interested in investigating this issue more, but you should take heed before delving deep into making a large PR - see later discussion in the PR I linked, and note this issue isn't labelled "help wanted". Fwiw, it's likely to be officially investigated and (hopefully) resolved during the extensionification.

[LukeSchlangen]

Ahhh... well that is a much larger issue than I thought. Seems like it's not something I have the knowledge-base to handle, so I'll hold tight!

[u-ndefine]

^{username: onlyNones}
This issue is still not fixed. This issue can be repro in Chrome. It's annoying when using the "of" block.

[adroitwhiz]

RIP extensionification 2019-2019. Looking into this now...

[adroitwhiz]

I have also determined that the following works too:

1. Change the selected sprite of the "() of ()" block in the Blocks Palette
2. Any block stacks on the current sprite will be moved to (0, 0) once the following steps are completed, unless you drag those stacks before taking the following steps.
3. Switch to any other sprite, which will cause the Blockly workspace to update
4. Switch back to the original sprite
5. Observe the breakage

This is a particularly insidious bug because the first time you change the sprite in the block's menu, nothing will appear to have gone wrong, but the blocks are still in a broken state. It's only when you switch between sprites that it actually takes effect, making it easy for users to mistakenly get into this state. That may also explain why this has been so hard to reproduce and inconsistent in the past.