Right- and left clicking at the same time will cause a block to be placed on top of a block, which then gets removed
if you stand on a block and have a block in your hand, jumping and then right clicking and left clicking at the same time will cause the block you were standing at to be 'moved' up. The block you were standing on will be deleted and a new block will be placed in the air. This works in any direction
Environment
Mac OSX Snow Leopard 32bit
Created Issue:
Right- and left clicking at the same time will cause a block to be placed on top of a block, which then gets removed
if you stand on a block and have a block in your hand, jumping and then right clicking and left clicking at the same time will cause the block you were standing at to be 'moved' up. The block you were standing on will be deleted and a new block will be placed in the air. This works in any direction
Environment
Mac OSX Snow Leopard 32bit
is duplicated by
is duplicated by
is duplicated by
is duplicated by
This ticket:
...quickly press right and then left click almost at the same time
Right- and left clicking at the same time...
Where is the difference?
Note: This is NOT a duplicate of MC-9686 which is a client bug, I am describing a Server issue + My issue works in Survival mode, too.
Reproduce
Join Server as non-op (works best with slow connection)
Locate Spawn area
Place block¹ on the Spawn border
Quickly place another block² on that block¹
Server will not accept block¹ and tell the Client to remove it
Server will accept block² although it has technically been placed on air
Result

The problem
when the client places a block in a restricted area and per lag it doesn't immediately get removed, you can place a block on that block (because the client still thinks it is there) even though there isn't a block to place it on. [...] it means that with a hacked client you can place a block anywhere regardless of wether there is a block to place it on.
Thanks Ezekiel for clarification ![]()
Fix
Do not allow to place Blocks on air
Leave a comment if you need more details
Confirmed.
Reason
The game loop happily handles both buttons in the same round, in the order left then right. The block and coordinates for the block that was aimed are kept the same (that is, it does not seem to recalculate the aim target after handling the first button. Thus, it first does left click (remove block) then immediately after does the right click (adds a block) as if the removed block is still there).
Now, one could think that the game checks if the block targeted can accept something to be attached to it. Nope. It only check the object being added if it has some objections to being attached to the target block. Apparently normal blocks have no objections of being attached to air.
One fix
Tested on 1.4.7. The fix makes the deletion of the aimed block (happens first) to also rescan for the new aimed block before applying block placement with the right click. Basically, the block under feet will be replaced with the block in hand.
Wouldn't this lag more?
It theoretically causes a tiny bit more processing overhead (which btw isn't 'lag') whenever the left mouse click is used, yes. But it should not be any considerable amount. I'll leave the testing and fine-tuning (or figuring out a better solution) for Mojang. For example, the initial call to getMouseOver is inside its own profiling section, so I'd guess Mojang would like to wrap that added call into one, too.
The solution I gave is more like proof of concept; proofs the reason for the bug, and that it can be fixed (easily).
Affects 13w09b.
Explain to me why this is a bug.
It only effects creative, where naturally you should be able to place blocks easier.
It is highly useful for placing pistons upside down.
It has no negative aspects, and is impossible to accidently do.
I used this behavior a ton, and now it is gone.
For reference: Seems this was "fixed" so that only the left click action (block removing) is done, right click action gets ignored when it happens simultaneously with a left click. (Didn't check the code, just the observed behavior in the client.)