Resolution: Won't Fix
Affects Version/s: 220.127.116.11 Beta, 18.104.22.168 Beta, 22.214.171.124 Beta, 126.96.36.199 Beta, 188.8.131.52 Beta, 184.108.40.206 Beta, 220.127.116.11 Beta, 18.104.22.168 Beta, 22.214.171.124 Beta, 126.96.36.199 Beta, 188.8.131.52 Beta, 184.108.40.206 Beta, 220.127.116.11 Beta, 18.104.22.168 Beta, 22.214.171.124 Beta, 126.96.36.199 Beta, 188.8.131.52 Beta, 184.108.40.206, 220.127.116.11, 1.14.30 Hotfix, 1.14.60 Hotfix, 1.16.0, 1.16.1
Fix Version/s: None
Platform:Windows 10 - PC
For simplicity, every time "input" is mentioned, it means walking, sneaking, sprinting, using an item or block, attacking a mob, or breaking a block.
If the player begins an input before or after entering an interface (such as a furnace, inventory, or chest) or changing game-states, once the player returns to the previous state (being able to move around), the input will not respond until the buttons are pressed again. This prevents persistent input after the following cases occur:
- Entering water (for sneaking only:
- Travelling through a nether or end portal
- Closing a chest, crafting table, book, pause screen, or other GUI
- Entering a world
- Pressing the "use/ right-mouse" button (for breaking blocks only; placing a block then immediately trying to break it, or simply pressing the "use/ right-mouse" button while breaking a block will stop the player from doing so)
- Scrolling through the hotbar (for breaking blocks, and using an item or block)
- Creative mode flying (for sneaking only)
- Leaving a mount (pig, strider, horse, or more related mobs; for sneaking only)
- Leaving a boat (for jumping and sneaking only)
Confirmed with keyboard/ mouse controls and a controller on Windows 10. If other devices are affected, this statement will be changed. The original reporter's information is retained below.
Scenario: Holding W and Ctrl when leaving the players inventory.
Expected: The player should start sprinting and moving forward
Actual Result: The player is standing still and is not sprinting
XBOX ONE BETA - Responsiveness in this case was as expected when using a controller.
WINDOWS 10/ANDROID (CONTROLLER) - While the sensitivity seems to be fixed, a behavior where something like holding down a button like L or R would not cycle continuously through the hot bar slots and instead only press once.
MOUSE(ANDROID) - Up until this point it has been impossible to implement a mouse API. However in Android release 8(codename OREO) an API was added for all public app developers. Not a bug just pointing it out.
If you need a better explanation, I be happy to provide footage of some examples. Please take note of this as I believe that this is a critically overlooked feature to be ported from Java Edition.