Block breaking is not canceled when losing focus of a block

Can't confirm in 1.8.3. Are you still experiencing the issue?

I'm still not experiencing this bug. Are you sure there aren't some other conditions causing it?

Can confirm for 1.8.6
Some other things I found:

• This bug only happens if you are only just able to reach the block when you start to break it - I found I had to be at least 4 1/3 blocks away from the block I was breaking.

• If you move back into this range between 4 1/3 blocks and the limit, you can continue to break the block.

• Once the glitch has happened, holding down left click while moving in and out of range will allow the block to be mined in stages provided the player does not mine any other block in that time. Left click does not have to be held down all the time, just when coming into range

The most pressing exploit of this is mining trees while jumping. When you jump, you are in block-breaking range of what is sometimes the topmost tree block and if you hold left click then occasionally after a handful of jumps you will partly mine the block. I assumed it was server lag when this happened to me but apparently not.

Confirmed. You must be at the extreme edge of the block-breaking range for this bug to occur. The easiest way to replicate this bug is to place a block 6 blocks above you, and jump at it while holding the mine button. The outstanding mining progress will reset itself after a few seconds if left alone.

can confirm in 1.20 Pre-release 1.

This seems to now effect even non-instant mined blocks in 1.20. Break any block anywhere with any tool, and then place a block where you just broke one, and there will be a stage 1 breaking animation. This is super distracting and buggy-looking.

Сan confirm 23w44a.

Can confirm in 1.20.6 and 24w21b.

The main cause of this behavior is MC-255057 (continuing to destroy a block only cares if the block that was last targetted is the same as the current block, not if you were still destroying a block).

This was introduced in 14w29a (a 1.8 snapshot), which changed MultiPlayerGameMode.stopDestroyBlock from

public void resetBlockRemoving()
    {
        if (this.isHittingBlock)
        {
            this.netClientHandler.addToSendQueue(new C07PacketPlayerDigging(1, this.currentBlockX, this.currentBlockY, this.currentblockZ, -1));
        }

        this.isHittingBlock = false;
        this.curBlockDamageMP = 0.0F;
        this.mc.theWorld.destroyBlockInWorldPartially(this.mc.thePlayer.getEntityId(), this.currentBlockX, this.currentBlockY, this.currentblockZ, -1);
    }

to

public void resetBlockRemoving()
    {
        if (this.isHittingBlock)
        {
            this.netClientHandler.addToSendQueue(new C07PacketPlayerDigging(C07PacketPlayerDigging.Action.ABORT_DESTROY_BLOCK, this.currentBlock, EnumFacing.DOWN));
            this.isHittingBlock = false;
            this.curBlockDamageMP = 0.0F;
            this.mc.theWorld.sendBlockBreakProgress(this.mc.thePlayer.getEntityId(), this.currentBlock, -1);
        }
    }

i.e. prior to that version, if a block was no longer targetted, then the break progress would be reset to 0, making things mostly behave normally (though it still would fail to tell the server that it started breaking the block, and redstone ore wouldn't begin to glow in this case).

I'm not sure why this change was made. The only relevant issue fixed in 14w29a is MC-676, but I don't think this change was directly part of that fix. So perhaps it was an intentional change, but it wasn't included in the changelog and is implemented fairly awkwardly.