Targeting blocks which extend outside of their space fails, causing the underlying block to be targeted instead

This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.

The bug

The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.

This is despite the fact that other block "hitboxes", such as its entity collision shape and visual wireframe, can extend outside of this space.

Current manifestations

This bug is responsible for the effects of the following two bugs:

• MC-124459: Far regions of extended piston heads' arms cannot be targeted

• MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted

In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.

How to reproduce

Reproduction steps exist in the two sub-issues, but are summarized here anyway.

Piston case

1. Place down a piston

2. Power the piston

3. Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston

4. Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head wasn't there
   

   [media][media]

Lectern case

1. Place a lectern sideways against a wall

2. Target this lectern and note the topmost region of the wireframe

3. Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
   

   [media][media]

Shulker box case

1. Open a shulker box which is beside a wall

2. Notice how the shulker box's wireframe expands to fit its opened state

3. When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
   

   [media][media]

Expected results

When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.

Actual results

Parts of the wireframe outside of the block are completely ignored.

Historical manifestations

Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs.

This list details most of the known cases; there are likely more that existed (one being moving pistons).

Offset dripstone case (MC-206643)

Resulted from the since-fixed MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.

Cakes/cacti float precision loss case

Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.

Overeaten cakes/overgrown stems case

Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:

Expected behaviour: Infdev signs

Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as expected: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.