Blobs2
- Blobs2
- blobs2
- Europe/Stockholm
- Yes
- No
MCPE-51440
I expect theMarketplace buttonto have a gray texture, similar to the other buttons on the main menu. However, this is not the case as of 1.13. Please fix it.The marketplace button appears different as of 1.13.0 and later.
How to Reproduce
This bug is very easy to reproduce. Just open Minecraft and look at the
The marketplace button appears different as of 1.13.0 and later.
How to Reproduce
This bug is very easy to reproduce. Just open Minecraft and look at the marketplace button. If you cannot reproduce this bug, deactivate all global resources and try again.Observed Results
The marketplace button has a background different from the other menu buttons, usually with an animation.Expected Results
The marketplace button should look similar to the other buttons. The only difference should be the word written on it.
Waterlogged pistons look glitched too; they flicker between the water and the piston. I usually think of this look as a Far Lands glitch.
I used commands to apply high levels of speed. As I saw my coordinates changing, the rate looked similar to what it is normally. I tested several levels of speed and got the same result.
How to reproduce:
- Sprint-fly in Creative to get a sense of how fast you are going.
- Use the command /effect @s speed 100 255.
Sprint-fly again, and notice that your speed is the same as it was before.I expected my speed to be much faster with the
effect, but it did not. Slowness also has no effect on flying in creative.This may be intentional, but I figured I would report it.
I used commands to apply high levels of speed. As I saw my coordinates changing, the rate looked similar to what it is normally. I tested several levels of speed and got the same result.
How to reproduce:
- Use the command /effect @s speed 100 255.
- Start walking, and notice yourself moving extremely fast.
- Enter flight mode, and notice that you fly at normal speed.
I expected my flying speed to be much faster with the status effect, as described in Step 2, but it did not. Slowness also has no effect on flying in creative.
This may be intentional, but I figured I would report it.
I used commands to apply high levels of speed
. As I saw my coordinates changing, the rate looked similar to what it is normally. I tested several levels of speed and got the same result.How to reproduce:
- Use the command /effect @s speed 100 255.
- Start walking, and notice yourself moving extremely fast.
- Enter flight mode, and notice that you fly at normal speed.
I expected my flying speed to be much faster with the status effect, as described in Step 2, but it did not. Slowness also has no effect on flying in creative.
This may be intentional, but I figured I would report it.
I used commands to apply high levels of speed, so I could fly very quickly, but this did not work.
How to reproduce:
- Use the command /effect @s speed 100 255.
- Start walking, and notice yourself moving extremely fast.
- Enter flight mode, and notice that you fly at normal speed.
I expected my flying speed to be much faster with the status effect, as described in Step 2, but it did not. Slowness also has no effect on flying in creative.
This may be intentional, but I figured I would report it.
I first noticed that TNT can destroy blocks farther away than minecarts. To test this properly, I recorded the damage that I receive at point-blank range. I used Resistance IV so these explosions would deal damage but not kill me.
How to reproduce:
- Surround yourself with obsidian, or another explosion-resistant block. Be sure to place a block above your head to prevent fall damage.
- Use /effect @s resistance 1000 3.
- Use /summon tnt ~ ~ ~ and notice that it deals 10 damage (this would be approximately 50 health without the status effect).
- Use /summon tnt_minecart ~ ~1 ~ and notice that it only deals 5 damage (roughly 25 without the status effect).
For comparison, creepers deal 8 damage at point-blank range with Resistance IV (roughly 40 damage without).
I expected TNT minecarts to deal 10 damage, like the TNT. This damage reduction may be intentional, but I figured I would report it.
Edit: According to the Minecraft Wiki, a TNT minecart has a more powerful explosion if it is moving faster. When I tested this bug, the minecart was always stationary. So this could be completely intentional.
This glitch can occur when throwing projectiles into portals. The details depend on the particlular projectile:
- It happens when throwing ender pearls into Nether portals. It does not happen when throwing ender pearls into End portals or End gateways.
- It happens when throwing ice bombs into Nether portals in Creative (but not in Survival). Occasionally it happens when throwing ice bombs into End gateways. It does not occur when throwing ice bombs into End portals.
- It does not occur with eggs or snowballs. I have not tested any other projectiles.
When this glitch does not occur for Nether portals, the projectile simply phases through the portal. When it does not occur for End Gateways, the projectile shatters on the player's end, causing expected results such as an ender pearl teleporting the player.To reproduce or test this glitch:
- Obtain the projectile you want to test. If you are testing ice bombs, the world must have "Education Edition" enabled.
- Create the portal you want to test. If you are testing End gateways, you will need to go to the End and defeat the Ender Dragon.
- If you are testing the glitch for Survival, switch game modes at this time.
- Throw the projectile into the portal. For End gateways, throw several projectiles.
- Finally, go through the portal and see if there is a ghost projectile on the other end.
Properties of a ghost projectile:
- They look exactly like the normal projectile.
- They stay perfectly still.
- They start on top of a solid block. However, they are not affected by gravity even if the block below is removed.
- They have no interaction with blocks or other entities. I am not sure if they can be moved by explosions, but I expect that they cannot.
As far as I know, the only way to get rid of a ghost projectile is to wait for it to despawn.This glitch can occur when throwing projectiles into portals. The details depend on the particlular projectile:
- It happens when throwing ender pearls into Nether portals. It does not happen when throwing ender pearls into End portals or End gateways.
- It happens when throwing ice bombs into Nether portals in Creative (but not in Survival). Occasionally it happens when throwing ice bombs into End gateways. It does not occur when throwing ice bombs into End portals.
- It does not occur with eggs or snowballs. I have not tested any other projectiles.
When this glitch does not occur for Nether portals, the projectile simply phases through the portal. When it does not occur for End Gateways, the projectile shatters on the player's end, causing expected results such as an ender pearl teleporting the player.To reproduce or test this glitch:
- Obtain the projectile you want to test. If you are testing ice bombs, the world must have "Education Edition" enabled.
- Create the portal you want to test. If you are testing End gateways, you will need to go to the End and defeat the Ender Dragon.
- If you are testing the glitch for Survival, switch game modes at this time.
- Throw the projectile into the portal. For End gateways, throw several projectiles.
- Finally, go through the portal and see if there is a ghost projectile on the other end.
Properties of a ghost projectile:
- They look exactly like the normal projectile.
- They stay perfectly still.
- They start on top of a solid block. However, they are not affected by gravity even if the block below is removed.
- They have no interaction with blocks or other entities. I am not sure if they can be moved by explosions, but I expect that they cannot.
- They are client-side, meaning that they disappear when you exit and re-enter the game.
When you have a wither in your world, and you exit and re-enter the game, the wither's x-position increments by 2. This also happens when you enter another dimension and return, but not when you move away from the wither (so it is beyond simulation distance) and return.
Edit: As of 1.16.50, the wither stays in place when you exit and re-enter the game. Also, it spawns 2 blocks east of where it was summoned (was 4 blocks). I think it's safe to say that this bug has been fixed.
How to reproduce
- Use /fill ~-10 ~2 ~-10 ~10 ~3~10 bedrock to create a 2-thick layer of bedrock.
- Use /summon wither ~~~.
- Break the bedrock at the wither's head. You should see the wither float upwards slightly.
- Exit and re-enter the game.
Expected result
The wither remains in the upside-down hole that you created in step 3.Actual result
The wither appears 2 blocks east of the hole. If you exit and re-enter the game enough times, the wither reaches the edge of the bedrock and flies away.Implications
This makes wither rose farms highly unreliable. I am not sure if it is even possible to create a permanent wither rose farm.Other notes
When spawning the wither (using soul sand or the /summon command) the wither appears 4 blocks east of where it should, which probably relates to this bug. In general, the wither's position in RAM is different from the wither's position in NBT.
To reproduce this bug, use zombie spawn eggs to create dozens of zombies. I expected a few of these zombies to be zombie villagers, but this was not the case.
Monster spawners appear to work fine; standing next to a zombie spawner (or cluster of zombie spawners) will eventually spawn a zombie villager.
Edit: It appears that zombies and zombie villagers are internally seperate mobs, so this my be intentional.
Affects version 1.14.30. Makes pistons an unreliable method of transporting the player or other entities.
My guess is that stronghold generation changed, since they are tied to villages. However, the command does not check that there is actually a structure if the terrain has already been generated.
Soul campfires drop charcoal in Bedrock Edition, while they drop soul soil in Java Edition.
How to Reproduce
Break a soul campfire without Silk Touch, and notice that it drops charcoal instead of soul soil.Impacts
This makes soul soil non-renewable in Bedrock Edition.Notes
I am not part of the beta, but I saw this difference added to the Minecraft wiki by BetaCarolina (see https://minecraft.gamepedia.com/index.php?title=Non-renewable_resource&diff=next&oldid=1552950 this edit). Feel free to resolve this as "Cannot Reproduce" if it is incorrect.
Soul campfires drop charcoal in Bedrock Edition, while they drop soul soil in Java Edition.
Edit: Soul campfires apparently drop 1 charcoal, while normal campfires drop 2.
How to Reproduce
Break a soul campfire without Silk Touch, and notice that it drops charcoal instead of soul soil.Impacts
This makes soul soil non-renewable in Bedrock Edition.
When you find a stronghold using eyes of ender or the /locate command, you are led to the "central spot" of the stronghold. In Java Edition, this spot is at the End portal, but in Bedrock Edition it is not.
How to reproduce
Use eyes of ender to find a stronghold. Make sure you know exactly where they are leading you, not just the general area. Alternatively, Dig down until you hit stone bricks.Expected result
The stronghold is centered on the End portal.
Actual result
The End portal is a distance away from the stronghold.
For reference, this happened on seed 1296937755. The stronghold was centered on X -702, Z 114. The portal room is at -707, 15, 158.
Edit: I tested this again in 1.16.50 on seed -904523900. The end portal is at 165, 21, 2342, but the stronghold is centered at X 162, Z 2290.
Impacts
This is probably the cause of
MCPE-52283, a bug where some strongholds generate with no portal room at all, but I am reporting it separately just in case.Even though most strongholds do have a portal room, it can be difficult to find because of this bug. This is a problem, since the End portal is (for most players) the main reason to find a stronghold.
Also affects 1.12.0
Things gradually break at excessive coordinates. Due to floating point precision errors, there are always slow speeds that become impossible.
Think of the world as composed of slices. You can move from one slice to another if you’re "attempted speed" is fast enough. However, if you are attempting to move less than a half slice per second, you get stuck in your current slice.
I’m no developer, but this bug may not be possible to fix. It shouldn’t affect players anyway; most people will not travel this far from the spawn point, place cobwebs on soul sand, or try to sneak while drawing back a bow, let alone combine all of these conditions.
Does this always happen if you stop moving at integer coordinates, or just when you cross a power of 2 at a slow speed? If it’s the latter, this bug would be easy to avoid; just like fault lines are risky IRL, powers of 2 are risky in Minecraft.
As someone who's interested in Far Lands glitches, I'd actually prefer this not fixed, as long as it is easy for players to avoid.
Edit: I did some testing in version 1.12.1. When I cross a power of 2 at the slowest speed, I fall through the world, as this bug states, but I also start falling through when I move to nearby locations, including before the power of 2. When I exit and re-enter the game, I stop falling through until I trigger the glitch again. This suggests that the initial fall puts the player in a state that allows further falling. If this state is that the player's hit box is 0, this would also explain why you fall through the world past 8,388,608 blocks, since the 0.3 blocks of hit box on each side round down to 0. However, I could be completely wrong, so I am not convinced that the glitch is as easy to avoid as I thought. Because of this, the bug should get fixed.
Silentwisperer uses this bug in mob farms. Fixing it would break these "trident killers".
Do the chunks all save at the same time? If not, that would explain the bug. Suppose chuck A saves, a mob from chunk B comes to chunk A, chunk B saves, and the game crashes before chunk A saves again. Then both chunks would have been saved without the mob.
I think a similar occurrence could cause mobs to duplicate. Has anyone observed this?
This should be fixed, for feature parity. Similarly, quasi-connectivity should be removed from Java or added to Bedrock.
This is a bug tracker, not a help site. Please explain what is happening and how to reproduce the bug, or it may get marked as invalid.
This is probably because all glow sticks have the same ID, with different damage values. Most items with durability are their own items (e.g., an iron sword and diamond sword are separate). Therefore, the grindstone is not programmed to check damage values, but this usually works fine.
The Bedrock Codebase is supposed to receive a flattening, similar to Java 1.13, which will remove damage values entirely. This bug should get fixed automatically when the flattening happens.
The game uses 32-bit floating-point integers for a lot of its calculations. These have 24 bits of precision. Past 2^18 blocks, 19 of these bits are before the decimal point, and 5 are after. Thus, the game cannot be more precise that a thirty-second of a block.
This is the reason the game breaks at excessive coordinates. There is no easy way to fix it.
In addition, almost no one would travel this far out, unless they want to experience the floating-point precision errors.
Looking at the screenshot, you are more than 128 blocks from the world origin, which should not be possible in old worlds.
@EndLordMC It shouldn't affect mob grinders, since drowned only drop tridents when killed by the player. If drowned drop tridents when they die naturally, then that is another bug.
@silentwisperer Another reason that Bedrock has no substitute for trident killers is that the AFK mob farms on Java require an auto-clicker. This would not work on mobile devices (assuming you are using touch controls) which comprise a large portion of the Bedrock players.
Can you destroy the other end crystals then defeat the Ender Dragon?
According to the Minecraft Wiki, observers detect block state changes on Java and block updates on Bedrock. The cause of this bug is that pumpkin and melon stems do not create block updates when they change state; only the pumpkin/melon itself does.
According to the Minecraft Wiki, observers detect block state changes on Java and block updates on Bedrock. This bug exists because rails do not create block updates when they re-orient.
I looked at the list of block states in the Bedrock Codebase. Apparently, there is a block state for the redstone power level, but not for which directions the redstone connects. Java Edition does have block states for the north, south, east, and west connections
This could be fixed by porting the Java block states, which I believe Mojang plans to do anyway (see https://minecraft.gamepedia.com/Official_pages/Bedrock_Edition_flattening).
I could not reproduce this bug in 1.13.3 on iOS. I started moving at the appropriate speed. I noticed the jitter associated with excessive coordinates (which I expected). As soon as I hit 65536, the jitter increased (frame rate cut in half) so I knew the floating-point precision errors increased at that moment. I became unable to move a fraction of a block after this, instead of right at 65536. Previously, I would become unable to move as soon as I cross a power of 2, and I would fall through the world.
This new effect happens at 131072 and 262144. I fell through the world at 524288, which is far enough out that it is not a concern.
Edit: A similar phenomenon happens in 1.14.0 (again on iOS) but I begin to fall through the world at 131072 blocks. While this is arguably worse, it is still beyond the "normal" coordinates, and the game starts to break anyway.
My concern is that if I create redstone contraptions now, and design them to work in spite of this bug, they may break when this bug is fixed. Please fix this ASAP so players can make contraptions that will continue to work in the future.
You mean 1.14.0. 1.15.0 was the bee update for Java.
As far as technical issues, it is likely because the block drops itself with data value 0. This happens to be the mushroom with pores on all sides.
Java Edition uses a block state for each of the 6 faces. Since block states are not stored when in item form, the "pores on all sides" appears when placing rather than when mining.
Bedrock is supposed to receive a flattening, which will include changes to many IDs, as well as block states. It should fix this bug automatically.
It appears that tridents can cause entities to clip through blocks. I am not sure how to generalize this glitch, but it is probably caused by trident knockback.
Could not reproduce in version 1.14.1. It may have been fixed.
Affects 1.14.1.
This is likely because minecraft:water and minecraft:flowing_water are separate IDs. They will be merged in The Flattening, which will hopefully fix this bug.
Please don't fix this. I have a stone generator that relies on waterlogged pistons. Basically, lava flows onto the space in front of a waterlogged piston, which pushes it out to create space for the lava to flow again.
Edit: As Amphy2k requested, here is a stone farm that uses waterlogged pistons. It is not exactly the same as my design, but it gives you an idea as to why this mechanic is useful. https://www.youtube.com/watch?v=cs-42ELOZzw
Apparently, sweet berry bushes damage mobs that are falling or pushing each other. However, slimes do not take damage when they jump and fall back down. Here is a more detailed sequence of steps to reproduce:
I was hoping I could use sweet berries in a mob farm until I discovered this bug.
This bug is only present if "Split Controls" is toggled off. As a result, it should primarily affect mobile devices.
I can confirm that trident hitboxes are at least half a block wide, which is larger than I would expect. The test involved floating-point precision errors, so I cannot give an exact size. However, the size rounds to at least a full block past 4,194,304, meaning that it is at least half a block in the playable region.
(Tested in 1.14.1 Hotfix on iOS)
I noticed more information about this bug that probably tells us what causes it how how to fix it. I did most of the testing at x: 131072 (the game is just starting to break at this point) but I can confirm it is possible to fall through the world at 2048 blocks.
The above information implies that the bug is an error in the cached coordinates of the player's hitbox corners. Normally, all hitbox corners move at the same speed, but I think this bug is caused by some corners moving at different speeds. Suppose you start at x: 2047.69, and you move at the critical speed. Then the following would happen:
If the front end of your hitbox is already past the boundary, then you still have a nonzero hitbox width at the end. If you hitbox is already partially collapsed, you can start less than 0.3 blocks from the boundary, and your hitbox will still be entirely within the boundary. This should explain all of my observations.
A possible fix would be to reset the player's hitbox periodically. It already resets when you exit and re-enter the game, when you use the /tp command, and in some other situation(s) that I am not able to reproduce. I measured and calculated that at 16384 blocks, there is a gap of just over 30 blocks between when you start moving and when you fall through the world. Thus, resetting the player's hitbox every 30 seconds would make it impossible to fall through the world at 16384 (32768 would be the lowest coordinates at which you can fall through the world). I am not sure whether the playable region should extend beyond 32768 blocks, but you get the idea.
@Silentwisperer While you can't push slabs or carpet with tridents on them, you can push tridents directly. I attached a screenshot of a working trident killer (tested using a repeating command block that constantly spawns zombies). The blocks in front are bottom slabs that you stand on. The rest is an observer clock that powers the pistons.
Pretty sure this is intentional. Snow golems do not produce snow in plains biomes or hotter. They definitely produce snow in forests.
Affects version 1.14.20, according to Truly Bedrock episode 53.
It appears that placing any non-waterloggable block at the location of the snow deletes the flower. Placing a waterloggable block in the space results in a "flowerlogged" block. Breaking the dirt under a flowerlogged block breaks the block that is covering the flower, and the flower hangs in mid-air until it receives a random tick.
This is not a feedback site. The Wither is intentionally hard to defeat.
They deal damage slower than in Java Edition (once every 2 seconds instead of every half second). However, I would consider this a parity issue rather than a bug.
Affects version 1.14.20
Affects version 1.14.20. I mostly play creative, but it could be a problem in survival because it drains your hunger bar.
Affects version 1.14.20 on iOS. The projectiles on the other end appear to be client-side because they are gone when I switch dimensions, or when I exit and re-enter the game.
I agree with 77Tigers. It is a very useful mechanic, such as in this mob farm by NavyNexus. Java Edition has quasi-connectivity and zero-ticking, while Bedrock Edition has sand pushers and trident killers.
This is definitely intentional. Sticky pistons can pull blocks, but they are otherwise the same as normal pistons.
Can a developer mark this "Works as Intended"?
Please give the steps to reproduce this bug.
Pretty sure this is intentional. The pistons are activated simultaneously, so the game handles them in a random order. The first piston to activate pushes the block; the second piston is unable to extend because there is a movingblock in the way.
Although the piston head is handled as a block entity rather than an actual block, the piston should just not extend.
The block deletes the flower if it is not waterloggable.
Additionally, breaking the dirt under a flowerlogged block breaks the block that is covering the flower, and the flower hangs in mid-air until it receives a random tick.
I could not reproduce this issue. The piston just breaks the bamboo and causes it to drop.
It is possible that the bamboo clipped through a block due to
MCPE-33715.Relates to MCPE-15793.
Duplicate of
MCPE-37825.This is because pistons are considered transparent.
Does the block disappear, or does it just not get placed? Test this in Survival to see if the number of blocks in your hand decreases.
Duplicate of
MCPE-49723.Affects version 1.14.30 Hotfix. Makes flying machines an unreliable transportation method.
Toycat has had this issue. It negatively impacts speedruns. https://www.youtube.com/watch?v=o47wJKyD5yY&t=41m30s
This adds new possibilities for wither cages and wither rose farms, so it could also be considered good.
This definitely needs to be fixed, so players have an easy way to prevent mobs from despawning.
This feature was stated in the change log, but never actually implemented.
Affects version 1.14.60.
The beacon beam is a block entity model, which yes, disappears before block models. I believe it renders as long as it is within simulation distance (which is separate from render distance. If you are worried about getting lost, turn on "Show coordinates", and record where your base is.
Duplicate of
MCPE-46865I observed the Overworld sky in the Nether; it doesn't just happen in the End. I also wouldn't be surprised if the Nether or End fog can appear in the Overworld. For reference, this happened in 1.14.60 on an iPhone 6S.
I accidentally entered a Nether portal in Creative. Due to the long loading screen, I quit out of the game and re-entered. One of the times I did this, I saw the loading screen for entering the Overworld, then I immediately started going the Nether. When I arrived, the Nether looked darker than it normally does. When I looked into the distance, I saw the Overworld fog.
I first learned of this bug in a video by ibxtoycat (https://www.youtube.com/watch?v=PSnresrIAfQ&t=12m55s). My encounter was similar to what he described: you enter a dimension and exit almost immediately. This implies that it is a lag-related glitch.
This should be fixed, as it is the primary method for breaking the bedrock ceiling in the Nether. For comparison, here is the behavior in Bedrock Edition.
You can push the bottom of an end crystal, and its fire will replace the pistonarmcollision. Since the visual piston head is technically the piston block entity model, what you see is a fire occupying the same space as the piston head. Unless you set the random tick speed to 0, the piston disappears after a few seconds (probably because the fire increments in age, which updates the piston). If the random tick speed is 0 (or if you are fast enough) placing a block next to the piston causes it to disappear.
I think it makes sense that headless pistons disappear upon receiving a block update. Porting this feature to Java Edition may or may not completely fix headless pistons, but it would prevent them from being used to break bedrock.
I think this is intentional.
This bug needs to be fixed before the final release. I was looking forward to building a magma cube farm using a bastion spawner.
This could potentially be exploited. On a given seed, you can copy the world several times, go to the same structure, and use the one with the best loot.
Duplicate of
MCPE-45657Duplicate of
MCPE-45657Duplicate of
MCPE-45657Duplicate of
MCPE-45657Duplicate of
MCPE-52283It appears that huge fungi can break bedrock; thus this bug should be considered an exploit.
I think the flint and steel automatically places normal fire. On the next tick, the fire responds to the block update (from its placement) and turns into soul fire.
The impacts of this bug are pretty minor; I can only think of uprooting mushroom by accident (since soul fire emits a lower light level) which is an edge case.
Duplicate of
MCPE-65382This issue breaks so many mob farms.
This happens despite the fact that they break slowly when mined by hand.
Also affects the chemistry tables, if the world has education features enabled.
This should be considered an exploit.
This is an exploit, as you can smelt a lot of items with just 1 bamboo. This is especially true if you have a spider farm, which will be easier to build in 1.16.0.
This was definitely introduced in the Buzzy Bees update for Java, but not for Bedrock. No idea why.
Only relates to
MC-180166. I don't think a Bedrock bug can be considered a duplicate of a Java bug.I don't think you could realistically use ghasts in basalt farms. They only shoot if there is a player with a direct line of sight.
The bug here isn't that nylium drops itself or doesn't drop itself. It is that there is a difference between editions.
Here's a quick update for those of you who are concerned. The Java bug report,
MC-172197, has been reopened to resolve this issue.Griefers could exploit this bug, by AFKing next to a wither cage. When the chunks load, the wither skulls could overload, or even crash, the server.
Idk whether they do in Java Edition. I thought they did, but I couldn't tell from 1.9+ video footage.
This is probably a duplicate of
MCPE-59523.Can confirm in version 1.16.201. According to the wiki, Protection reduces damage from all sources except the void, /kill, and hunger. But in Bedrock Edition, you are also not protected from status effects or suffocation.
Pretty sure this is intended. The enchantment is supposed to protect you from everything except the void, /kill, and hunger. Note that it does not protect you from status effects or suffocation; see
MCPE-92883.Duplicate of
MCPE-40651.Can confirm in 1.16.201. Resistance V acts like resistance IV, but any higher level gives full protection.
As Dragonairre said, this is intended. Protection is supposed to reduce almost all damage. It does not protect you from status effects; see
MCPE-40651.I cannot reproduce this for /enchant; I get the correct enchantment. It does happen for /effect, but this is an intended feature.
Generally, items get more expensive each time you work on them. It is better to combine items into pairs, then combine these pairs, and repeat until all enchantments.
Can confirm for iOS and Android. I will note that dyed cauldrons have the correct texture; this bug only affects undyed cauldrons.
This is probably intentional. On an intuitive level, fish items look like whole fish, implying that a fish mob drops its entire body, so it doesn't make sense to get multiple fish from one. From a parity standpoint, I'm a Bedrock player and can confirm the "bug" on this edition too.