The five attached screenshots do a good job of explaining part of the problem. Here are reproduction steps for a more complete representation:
1. /clear
2. Put 2 stacks of stone in your inventory and 2 stacks of stone in your hotbar
3. Grab any other item, perhaps a grass block, and shift-double-click one of the stacks of stone in your inventory with it
Expected: 4 stacks of stone in the hotbar. Actual: 4 stacks of stone in the inventory.
MC-13289 suggests that this is indeed a bug.
Linked issues
is duplicated by 2
Attachments
Comments 13
Hm, then either this ticket or MC-13289 is working as intended.
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
This happens because this logic in AbstractContainerScreen.mouseReleased assumes that the slots belonging to the same “quick move group” as the targeted slot can be found by finding all slots belonging to the same container, when in the player inventory the two groups, being the 9x3 inventory and the hotbar, are both part of the player inventory:
for (Slot $$6 : this.menu.slots) {
if ($$6 != null
&& $$6.mayPickup(this.minecraft.player)
&& $$6.hasItem()
&& $$6.container == $$1.container
&& AbstractContainerMenu.canItemQuickReplace($$6, this.lastQuickMoved, true)) {
this.slotClicked($$6, $$6.index, $$0.button(), ClickType.QUICK_MOVE);
}
}As a result the code will always trigger a “shift click” on all items of the given type in both the inventory and the botbar, regardless of where you click. The actual shift click behavior in the container menu implementations on the other hand is hardcoded to move items from certain slot ranges to others, without regard for Slot.container.
Does MC-13289 describe your issue ?
If not, please attach screenshots.