Code analysis by @unknown can be found in this comment.
Related issues
is duplicated by
Attachments
Comments

Can confirm.
Confirmed for 15w50a

Still an issue in 15w51b

still seems to be an issue in 16w02a

Issue confirmed for 16w02a.

Issue in 16w03a
Confirmed for 16w04a
Confirmed for 16w05a
Confirmed for 16w05b

Still an issue in 16w06a
Confirmed for 16w07a
Confirmed for 16w07b

Still an issue in 1.9-pre1

Still an issue in 1.9 Pre-Release 2

Pressing Shift you can hear the sound, without pressing it the issue stills there. Tested on 1.9 Pre-Release 1

Confirmed for Pre-Release 2
Confirmed for 1.9 Pre-Release 3

Confirmed for 1.9 Pre3

please help Mojang out by not posting a comment that's the same a one before it, they're swamped enough as it is.

Confirmed for 1.9 Pre-Release 4

Confirmed for 1.9 ..

More detail in 1.9:
If you shift-click while placing a block on the fence, it makes the proper placement sound. This seems to be an interaction between the "attempting to 'use' item/tool on the fencepost" and "attempting to place a block on the fencepost" functions, as seen when you try to eat food while having the cursor over a fencepost.
Confirmed for 1.9.1 Pre-Release 1
Confirmed for 1.9.1 Pre-Release 2
Confirmed for 1.9.1 Pre-Release 3

bug is still here - 1.9.2

Please link to this comment in the description
The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta. All method and class names are the names used in the decompiled version.
The reason why this happens is because the method net.minecraft.block.BlockFence.onBlockActivated(World, BlockPos, IBlockState, EntityPlayer, EnumHand, ItemStack, EnumFacing, float, float, float)
returns for the client always true
, this means the client always acts as if it interacted with the fence.
In general the client places a block which creates the sound and sends a packet to the server. The server creates the sound then for all other players because it assumes the client placing the block acted the same way the server did and already played the sound.
The problem is that the client did not play the sound, but the server does not know that.
This could be solved by sending the server also what the client thought would happen. In this case interacting with the fence instead of placing a block. Then the server could send the sound to this client as well if the action differs from the one the server did.
Confirmed for 16w14a
Confirmed for 16w15a
Confirmed for 16w15b
Confirmed for 1.9.3 Pre-Release 1
Confirmed for 1.9.3 Pre-Release 2
Confirmed for 1.9.3 Pre-Release 3
Still in 1.9.4
Confirmed for 16w20a
Still in 16w21a and 16w21b

Still in 1.10 pre1
Confirmed for 1.10-pre2

confirmed for 1.10

Confirmed for 1.10 : All Versions
Still broken since 1.9. Fix in plan?
It does play a sound when shift-right click.
Confirmed for 1.10.2

Underlying cause is MC-21433 (which is WIA :/)

That is not quite the problem here as the block is placed. The problem is that the client always asumes that it interacted with the fence whereas the server does not behave like this and places the block.


Sorry, yes you are right. I thought they acted the same way iron doors or trapdoors act.
Mods please do not close this report as a duplicate because then we have an unnecessary discussion about whether or not it is WAI and like @unknown said it is definitely not.
I would suggest fixing it by having client and server call the method net.minecraft.item.ItemLead.attachToFence(EntityPlayer, World, BlockPos)
but change this method to only create the LeashKnot and leash the entity server-side.
Note: The method net.minecraft.item.ItemLead.onItemUse(ItemStack, EntityPlayer, World, BlockPos, EnumHand, EnumFacing, float, float, float)
contains kind of dead code because if the player successfully interacts with a block it will not use the item. If the player fails right clicking while holding a leash, this method will fail as well.
Still in 16w38a.