What I expected to happen was...:
A redstone signal to disable a hopper.
What actually happened was...:
Hoppers are always enabled even when powered.
Steps to Reproduce:
1. Place a hopper
2. Place a lever or redstone block beside it.
3. Flip lever and throw something into hopper (see that it is not disabled as it should be).
Proof: http://youtu.be/jIceCz2QQzI
Related issues
Attachments
Comments


Cannot reproduce.

The problem seems to be that the client does not know that the state of the hopper has changed, not that it is non-responsive. The hopper still functions as expected. The hopper can be updated if a block is directly placed on the hopper. (Meaning the hopper is the block clicked on to place the block)

#1 - Just placed down hopper (enabled:true)
#2 - Redstone block added by (enabled:true)
#3 - Block update on top of hopper (enabled:false)
#4 - Removed redstone block and update block (enabled:false, should be enabled:true) - needs block updated to get enabled:true

Adam is correct. It did not update because of a client site bug.
A redstone block or other redstone device doesn't update the state of the hopper unless it is interacted by the player or has a block update (another block is placed on top). See graphics.

You need to clarify this bug. At first I thought there was nothing wrong.
Note: The hopper does work correctly. Your bug title is misleading since the hopper is responsive to redstone.
But the bug should be clarified to explain the on F3, enabled does not get updated correctly unless the GUI is viewed.

This ticket has been marked as a duplicate of MC-70127, in favor of the more general or better information provided.