Bug with Send to Back/Front & Set Z Order

After Send to Back is used in a project, using Set Z Order on a different object affects the relative z order of the 1st objects (that were ordered using Send to Back)

Expected behavior: Changing the Z order of object A should not affect the relative z order of objects B & C.

Simple project to show the bug

Note both before & after, the z order value of the objects ordered using Send to Back is 0

————————————
Device: iPad7,11
iOS Version: 14.7.1
Hopscotch Version: 3.47.3
Player Version: 1.5.18

9 Likes

Thanks for creating this report, and taking the time to isolate it and make an example. I added it to our list to triage (I will just double-check if it’s unintentional with the z-index relative to Send to Back case, since I’m not sure if Send to Back just uses a specific Z-index or something similar.) And I included another test case here.

(description) Objects that have been Sent to Back/Front have their Z-order affected unexpectedly, when another object uses Set Z-index

Steps to Reproduce

  1. Drag out three objects onto the stage, that mainly overlap each other e.g. Cody, Star Girl and then Dino
  2. For Cody, add When game starts and Send to Back.
  3. For Dino, add When game starts, and Wait 5 seconds, then Set Z-Index to -1

Expected outcome:

  • When the game starts, Cody is behind Star Girl.

    Order of characters, from behind to front:

    Character Z-index / Z-index state
    Cody sent to back
    Star Girl 0
    Dino 0 (added to the editor after Star Girl)
  • After 5 seconds, Dino would be set behind Star Girl. But Cody would remain at the very back because he has been sent to back, regardless of the number that Dino’s Z-index is set to.

    Order of characters, from behind to front:

    Character Z-index / Z-index state
    Cody sent to back
    Dino -1
    Star Girl 0

Actual outcome:

  • When the game starts, Cody is behind Star Girl.

    Order of characters, from behind to front:

    Character Z-index / Z-index state
    Cody sent to back
    Star Girl 0
    Dino 0 (added to the editor after Star Girl)
  • After 5 seconds, Cody is in front of Star Girl and in front of Dino, despite having been sent to be behind Star Girl earlier.

    Order of characters, from behind to front:

    Character Z-index / Z-index state
    Dino -1
    Star Girl 0
    Cody sent to back
7 Likes

I remember somebody saying something about that z index only supports positive numbers.

2 Likes

Hi Innerpanda, considering whether the issue is related to negative values is a good thought.

Using T1’s example, we can modify it like this

Which, after Game Starts, will be ordered (back to front)

  1. Cody
  2. Star Girl
  3. Dino

After Dino sets their Z index to 2, the order should not change.

But Cody & Star Girl still switch when they shouldn’t. The order becomes

  1. Star Girl
  2. Cody
  3. Dino

So the behavior isn’t related to negative Z indexes. But that was still a good exercise to prove out :+1:

5 Likes

Ok so at the moment, Bring to Front / Send to Back don’t currently use Z-index directly.


The team were discussing this, and I was also curious to hear others’ thoughts on what expected behaviour should be.

I wrote this as well:

Usually when people use the Bring to Front / Send to Back blocks, it would be expected that that outweighs whatever the other objects’ z-indices are (Bring to front and Send to back are both superlatives).

At the moment, it seems that when an object is sent to the back, and another object subsequently changes its own Z index to a specific number (e.g. 2, -1, etc.), the initial object is no longer at the back (it goes in front of another object that has had no Z-ordering change applied to it.)

I guess a solution could be:

Changing the Z order of object A should not affect the relative [or superlative] z order of objects B & C. —ThinBuffalo

Using Bring to Front / Send to Back would make the object stay at the very front or very back, until its own Z index has been manually set to a specific number, regardless of whatever absolute number the other objects’ Z-indices are subsequently set to. When its Z-index has been set to a specific number, then it can be compared to the Z-index of other objects and re-ordered accordingly.

Otherwise, it should remain at the very front or very back, until another object has subsequently been brought to front or sent to back.

But in regards to this:

I’m not sure yet what the z-index should be when others try to check that value through the z-index trait though

2 Likes

Hi t1, first let me stay that it’s really great that you take the time to engage with the community. I was waiting to see if others would chime in but since no one has, I’ll offer my thoughts.

Let’s call this Option A

I could see that as one perfectly valid option, with the other Option B being:

Bring to Front / Send to Back move the object to one end of the Z order “stack” & assign it the corresponding Z index of that position. In this way, it’s more of a Bring to Front / Send to Back just relative to the current spread of Z indicies rather than a Bring to Front / Send to Back and stay there. The initial effect visually would be the same. With difference being that another object could move itself to the back/front by setting an even lower or higher Z index.

Even with Option A you could assign Z indicies after Bring to Front / Send to Back, just to do away with the potentially confusing value of 0. Conveniently JavaScript (well actually the ECMAScript standard) has values for Number.NEGATIVE_INFINITY and Number.POSITIVE_INFINITY which would seem to match your behavioral description (these values can even be used in Hopscotch today by entering -∞ and +∞ into a number bubble)


For whatever it’s worth, my assumption would have been Option B where Bring to Front / Send to Back, rather than being a persistent assertion, is more of a function for referring to the “min/max of the collection of all object’s Z_indicies”.

Otherwise with Option A, I believe Bring to Front / Send to Back could be viewed as object attributes in of themselves, since they would be a persistent assertion. I think it’s this distinction that caused me to initially expect Option B.

Which is better? :man_shrugging:

2 Likes

Oh yeah I see what you mean — Option B does make sense to me as well, that the Send to Back and Bring to Front are stacked relative to the current Z-index values in the project.
I did include what you have said as well. And I did not know about the ±∞ values — that is really interesting.