KamiADN

Any way to appeal the closure of this issue?

That’s probably related to that recent fix MC-276264 .

I really don't know, but in any case, that is a common technique used in RP and I think it is a big loss, so a solution or an alterantive would be appreciated.

That's still present in 23w14a.

I think is in part a hardware issue, but as many of you state, it only happens on Minecraft...

Windows 11 with Razer Blackwidow v3 mini (Wireless) with Spanish layout.

Since there are already many ways to replicate that issue, i'm commenting to post some help for people that needs a tempotary workaround while that bug is still present because that makes the game super anoying for those who like me works with commands a lot of the time.

If you are a Windows user, you can use the "Microsoft PowerToys" and use the integrated Keybaord Manager to translate "Alt (Right)" into "Ctrl (Left) + Alt (Left) + Undefined". It may look like it will do nothing, but for me it prevents the bad behaviour in Minecraft while the keyboard still works as normal in any environment.

Confirming it's still present in the latest snapshots

Confirmed for 1.14.4

Still present in 1.14.2.
Since I can't reproduce it with "fill" commands...
The fastest way to cause the bug is "using another bug". I explain it:
Flat world
Spawn a villager in a 3x3 hole.
Equip yourself on the hotbar a Workstation, for example a lectern.
Now you can simply place and break a lectern until it happens, but the fastest way is as follows:
Change "Place block" action to key "F"
Change "Destroy block" action to key "E"
Place the lectern.
Now, close to it (to avoid placing more than one block), hold E (to destroy it) and then hold F (to place it). (In this order, so the game prioritizes placing blocks faster than it breaks them).
(This should make the "place-break-place-break" action very fast, making the bug appear with a few attempts) (It's easier this way thanks to this other bug -> MC-118107 , in which "the last key that is kept pressed, repeats the action very quickly).
(I use the keyboard with this configuration because I usually play like this, and that's how I discovered that the bug persists)
I hope that the steps, though confusing in theory, will be simple to reproduce for you in practice.

With the new system of data-driven loot tables for blocks... is it still working as intended? if I can now make a spawner loot table with "copy_nbt" and get that block in "survival"... shouldn't i be able to place it with his current tags?

Xisumavoid showed that as "maybe a feature" in one video... and maybe that's what you remember... but yes, it's a bug.

Confirmed on: 1.13-pre4, 1.13-pre5

Also, one way to avoid this strange behavior is to hold down the first key and simply press another key. For example, hold "e" (linked to breaking blocks) and then jump with space. If you have not released the "e" key, it works as it should.... I think this has happened since the LWJGL was updated in one of the early snapshots of 1.13.

This must be related to MC-118107 

Confirmed on: 18w22b, 1.13-pre1, 1.13-pre2

Confirmed on 18w08b and 18w09a.

Confirmed on both 18w06a and 18w07a!

Another week, still confirmed on 18w05a.
I don't know if I can, but if I were the reporter, I could change it myself, right?
In the meantime, I will continue to confirm the bug every snapshot, hoping that they will fix it Soon™.

Thanks for the answers, I'll just keep making comments. I simply wanted to make your work as easy as possible. This bug occurred on 1.12.2 and earlier, but since the first snapshot of 1.13 it always occurs. Although the bug is the same, I think the origin is different now, maybe the change of the lwjgl version. But I have no idea.

Confirmed on 18w03b. Is there another way to continue confirming a bug without spamming comments?

Confirmed 18w02a

Still present in 18w01a

Confirmed on 17w48a