SchimmelGelenk

Looking at the code for 1.27.1, the process is not very complex, but spans across many classes. In short the Zombie entity class, has the behavioural goal class ZombieAttackTurtleEggGoal, which implements the egg breaking. This is a subclass of RemoveBlockGoal. There I found:

//net.minecraft.world.entity.ai.goal.RemoveBlockGoal
@Override
    public void stop() {
        super.stop();
        this.removerMob.fallDistance = 1.0;
    }

This function is called once the goal is not active any more. In this example that is when the turtle eggs are broken or inaccessible. Here we can see this sets the fall distance to 1, which can be confirmed with the /data command ingame and thus explains the issue.

Interestingly, I made another discovery while looking at the code. For context, this bug was found while trying to find the reason, why zombified piglins where rarely surviving in a fall damage farm. In the superclass of the RemoveBlockGoal class:

//net.minecraft.world.entity.ai.goal.MoveToBlockGoal
@Override
    public boolean canContinueToUse() {
        return this.tryTicks >= -this.maxStayTicks && this.tryTicks <= 1200 && this.isValidTarget(this.mob.level(), this.blockPos);
    }

This function is called every tick. If it returns false, the goal stops. So in this context, the zombie fall distance gets set to 1. Relevant here is the second conditon that is checked: this.tryTicks <= 1200. That means after 1200 ticks or 60 seconds, the function returns false, the goal is not active anymore and the fall distance is set to 1. For example:

A zombified piglin (or any other type of zombie) spawns in range of turtle eggs, it walks towards them and takes a long time to do so for some reason. As it reaches the eggs, it falls into the farm and mid fall the 1200 ticks are reached, the turtle egg goal will not be active anymore. Thus the fall distance is set to 1, by the stop function of the RemoveBlockGoal class and the zombified piglin will survive the deadly fall.

In my eyes this is not a seperate issue, as the underlying problem is in both cases the fall distance reset. But it is a relevant consequence of it.

Not only is this a UI issue, you can interact with the chests if you input fast enough. Meaning you can put items into chests whilst being in the portal, which I tried (see

). Thus also taking items out but I was not able to do this.

Maybe this is still worth fixing, considering the problems and bugs may arise from inserting items into chest just as the dimension changes. Like duping on servers and such.

Also confirmed in 1.20.2 if that is even relevant ,)

Since 1.19-pre2 is not affected and 1.19-pre3 is, I did a small code analysis. I decompile both versions using hube12/DecompilerMC and compared Blocks.java.

net.minecraft.world.level.block.Blocks.java line 344

// in 1.19-pre2
public static final Block MANGROVE_ROOTS = Blocks.register("mangrove_roots", new MangroveRootsBlock(BlockBehaviour.Properties.of(Material.WOOD, MaterialColor.PODZOL).strength(0.7f).randomTicks().sound(SoundType.MANGROVE_ROOTS).noOcclusion().isValidSpawn((arg_0, arg_1, arg_2, arg_3) -> Blocks.ocelotOrParrot(arg_0, arg_1, arg_2, arg_3)).isSuffocating((arg_0, arg_1, arg_2) -> Blocks.never(arg_0, arg_1, arg_2)).isViewBlocking((arg_0, arg_1, arg_2) -> Blocks.never(arg_0, arg_1, arg_2)).noOcclusion()));

// in 1.19-pre3
public static final Block MANGROVE_ROOTS = Blocks.register("mangrove_roots", new MangroveRootsBlock(BlockBehaviour.Properties.of(Material.WOOD, MaterialColor.PODZOL).strength(0.7f).randomTicks().sound(SoundType.MANGROVE_ROOTS).noOcclusion().isSuffocating((arg_0, arg_1, arg_2) -> Blocks.never(arg_0, arg_1, arg_2)).isViewBlocking((arg_0, arg_1, arg_2) -> Blocks.never(arg_0, arg_1, arg_2)).noOcclusion()));

Notice that the bold part is missing in version 1.19-pre3 is the attribute .isValidSpawn. Both the name and it's removal point to the issue on hand. I added to the before mentioned missing part to the 1.19.4 source code using Hexeption/MCP-Reborn and compiled the code to a .jar. In this modified version of Minecraft version 1.19.4 mobs do not spawn on mangrove roots, as intended.

Thanks chrrs for the help.

+1 Birder24's comment

1.19 pre release 2 not affected

1.19 pre release 3 is affected

can confirm 1.19