Local variables are shared between sprites

[apple502j]

Expected Behavior

Local variables should not be shared between sprites

Actual Behavior

https://scratch.mit.edu/projects/398917160/ has a local variable ~LOCAL_A that is shared between sprite A and B. The creator didn't say they uploaded the sprite or used backpack, so not #1766 or #1375

WARNING: THE PROJECT LAGS, SEE BELOW FOR WHY

You can see that it's the same sprite because it has the same variable ID:

I've run vm.setVariableValue(vm.runtime.targets[2].id, ")|vidmn.3H1=f_,R7RF_", 1) to see how things will be and the result is:

I ran refreshWorkspace just to see what happens, and it had no effect. Then I tried switching between sprites and the value still didn't update.

Steps to Reproduce

ggenije said lagging the editor while switching the sprites have something to do with this.

Operating System and Browser

My browser / operating system: Windows NT 10.0, Chrome 81.0.4044.138, No Flash version detected

Thanks ggenije for reporting this bug!

[BryceLTaylor]

I was able to reproduce this issue by dragging the same sprite with a variable out of my backpack twice. The two sprites can access their own copy of the variable separately (changing the value in one doesn't change it in the other.) It does, however, interfere with monitors. You can only show the monitor for one of the two monitors. It looked to me like it was for the first one, but I haven't explored it too closely yet.

Here is a project that shows the results. https://scratch.mit.edu/projects/399215564/ Note, if you press space it increases the variable "local" for one sprite, and pressing up increases the local variable "local" in the other one. They both have the same id for the variable.

[apple502j]

@BryceLTaylor The backpack one is #1375 - and the user said they didn't use code from backpacks

[apple502j]

One possible repro:

• https://scratch.mit.edu/discuss/post/4175550/

[lintense]

Hi guys!
This issue is not directly related to the backpack but solving it should help (and maybe fix) the backpack one.
(I'm thinking about #1766 for instance)

The current issue is two fold and is indeed very easy to reproduce:

Part 1
1-Create a new project
2-In the default sprite: create a new LOCAL variable named "V"
3-Duplicate the default sprite
4-In the new sprite (aka sprite2): create a new LOCAL variable named "V"
Result: The system PREVENTS the creation saying the name are conflicting.
Expected result: The system should accept the new variable since it is not "really" conflicting.

Part 2
1-Create a new project
2-In the default sprite: create a new LOCAL variable named "V"
3-In the code section create a <Set variable V to '1'> block
4-Click on the <Set variable V to '1'> block to set the local value to 1
3-Put the default sprite in the backpack
4-Drop the default sprite from the backpack
Result: The system allows the dropping hence creating a "copy" of the LOCAL variable but the variable is "shadowed" by the Sprite1:v variable.

5-Change the Sprite2:<Set variable V to '1'> block to <Set variable V to '2'>
6-Click on the Sprite2:<Set variable V to '2'> block to set its local value to 2
Result: The value is not updated. (actually it is but it is shadowed but the Sprite1 local variable)

7-Delete Sprite1
8-Check the Sprite2:v variable box in order to view its value
Result: The Sprite2:v was indeed correctly set to 2
Expected result: The system should not shadow the local variable and simply treat them in a completely separated manner.

A naive solution would be append some kind of a unique sprite id at the beginning of the (inner: inside the VM) local variable name. This would differentiate them both upon creation and on backback dropping.

Hope this is helping!

[Tacodiva]

...over a year later. I have worked what is happening in laggy projects that causes this bug! You can repeat my steps using this project https://scratch.mit.edu/projects/568668981/
In the project above, the cat sprite is setup with two local variables and a large amount of Move 10 steps blocks to cause lag when switching to it. The bear sprite is empty.

1. Have the bear sprite selected
2. Switch to the cat sprite. This should cause scratch to hang for a second, as the sprite contains a lot of blocks.
3. While in this lag, re-select the bear sprite again. This should cause scratch to quickly switch to the cat sprite than back to the bear sprite again.
4. From my tests, there's around a 50% chance that all the local variables from the Cat will now be present in the bear.

Here is a screen recording of me showing this happening https://youtu.be/280JWhKwaCc
I do the switching, it fails twice but on the third attempt the variables are duplicated. This bug also occurs with private lists. I would really like to see this issue fixed, as I am working on a large project where this happens frequently, and it's very annoying to clean up after.

[apple502j]

@Tacodude7729 Thanks for the repro! Yes, I can now reliably reproduce the issue. I think this is related to Blockly auto-creating variables, but checking editingTarget at the wrong time.