plighting

This happens because the deep dark and dripstone caves use the "flower_plain" configured feature, which is used for plains biomes as well. In Bedrock Edition, the deep dark and dripstone caves use the bedrock equivalent of the "flower_default" configured feature, which only uses poppies and dandelions. To fix this, instead of using 

DefaultBiomeFeatures.addPlainsFeatures(var3);

in dripstone caves and deep dark biomes, it should use

DefaultBiomeFeatures.addDefaultFlowers(var4);

In summary: this is due to these 2 biomes using the wrong configured feature. This is also a parity issue.

Took me a few hours to find one with black colors but can confirm in 1.20.4

Also here is some code analysis (Code is decompiled using Mojang Intermediary mappings):

This bug was introduced in 1.19.3 (as the poster correctly notes). The code for tropical fish variants was rewritten then and the way the random color was generated got changed too.

There is an array at DyeColor.values which contains 16 colors with black being the last (the 15th if you start counting from 0). Pre-1.19.3, a random number was generated from 0-14 for the color, meaning black (the color in the 15th place) was never chosen. However, when the code was rewritten, that behavior was not maintained due to an oversight. Now, instead of using random.nextInt(15), it uses net.minecraft.Util.getRandom, which returns a random element of whatever array is passed into it. This means that black is a valid color for the base color or pattern color to be now, which was not intended.

The below code is from 1.19.2 (before the bug): each property (in order: base, pattern, base color, pattern color) is randomly generated, then squashed into one value which is later interpreted elsewhere. Note that the last two (base color and pattern color) use a number from 0-15:

else {
        this.isSchool = false;
        var6 = var10.nextInt(2);
        var7 = var10.nextInt(6);
        var8 = var10.nextInt(15);
        var9 = var10.nextInt(15);
    }
this.setVariant(var6 | var7 << 8 | var8 << 16 | var9 << 24);
return var4;

Since 1.19.3, the above code now looks like this, where Util.getRandom is called instead of random.nextInt:

else {
        this.isSchool = false;
        TropicalFish.Pattern[] var9 = TropicalFish.Pattern.values();
        DyeColor[] var10 = DyeColor.values();
        TropicalFish.Pattern var11 = Util.getRandom(var9, var7);
        DyeColor var12 = Util.getRandom(var10, var7);
        DyeColor var13 = Util.getRandom(var10, var7);
        var6 = new TropicalFish.Variant(var11, var12, var13);
    }
this.setPackedVariant(var6.getPackedId());
return var4;

The DyeColor.values array is below:

{WHITE, ORANGE, MAGENTA, LIGHT_BLUE, YELLOW, LIME, PINK, GRAY, LIGHT_GRAY, CYAN, PURPLE, BLUE, BROWN, GREEN, RED, BLACK}

This is now even more of an issue with the introduction of trial chambers - spiders spawned there will often get stuck in high places where you won't see them, meaning you won't be able to complete the trial spawner and get the loot. This detracts from the experience significantly.

Can confirm - it seems like if the step height is greater than the height you would step up plus the height of the air space, it will fail.

Can confirm.

Can confirm.

Can confirm.

Can confirm. Also, the sound for this does exist in game and can be accessed with this command:

/playsound minecraft:entity.armadillo.unroll master @a

Also, relates to MCPE-177562

Can confirm on Windows as well. I believe that this is not a device-specific problem.

Ok, thank you

In Minecraft Bedrock, the correct command is /fill ~~~ ~~~ stone_block_slab["stone_slab_type"="stone_brick"]

This now is also going to affect short grass (as grass got renamed to short grass in java 1.20.3 pre1)

Note: the Minecraft wiki link in this post links to the old wiki still 😞 

Looks like it's been fixed here!

This issue is a bit broader that what is mentioned in the report. This does not only affect entering sneaking, but changing between all heights. Whatever height you were at before being clipped inside of the block is what you will be stuck in. For example, if you crawl under a trapdoor, then move against the block that the trapdoor is attached to and close the trapdoor again, you will be stuck in crawl mode. See the attached screenshot.

Furthermore, from my testing, this does not only affect the animation, but behavior as well. By following the steps to reproduce the bug in from the report, I still moved at walking speed. Additionally, this affects the player's hitbox - when attempting to sneak in a door, the player's hitbox does not change; when closing a trapdoor on the player in crawl mode, the hitbox of the player is still in crawl mode. The only effect of sneaking that I experienced when in a door was not falling off the edge of blocks.

Also, can confirm in 1.20.3 Pre-Release 2.

Tuff bricks are now in the game as well. They are also crafted with polished tuff, so polished blackstone bricks are incorrect, right?

Your skin was rotated 90° to the right. Attached is a fixed version for you:

Can confirm in 1.20.2.

That is true, sorry

Relates to MC-266101. This report is not duplicated by MC-266101, contrary to how it is marked. They are reporting separate issues.

Same cause as MC-266125