Note:
For simplicity, every time "input" is mentioned, it means walking, sneaking, sprinting, using an item or block, attacking a mob, or breaking a block.
The bug
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: MCPE-39970)
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.
KEYBOARD(WINDOWS 10/ANDROID):
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.
Linked issues
is duplicated by 7
MCPE-53523
Input Errors and Inputs not Updating (Keyboard and Mouse)
Resolved
MCPE-57017
Holding crouch and opening inventory un-crouches after leaving inventory
Resolved
MCPE-114230
Swapping item with mouse wheel stops using/mining/placing, even if mouse 1 is still held
Resolved
MCPE-125059
Scrolling Mouse Wheel while placing blocks doesnt work.
Resolved
MCPE-137949
mining can be canceled while holding button
Resolved
Comments 11
Better Explanation: On Java if you hold a Key before leaving the inventory, it will trigger when you leave (For example holding forward(w)) This inconsistency has constantly bugged me and many other players who had played Java extensively.
Cleaning up old tickets: This ticket has not been updated recently (1 year+) so is being closed as Cannot Reproduce. If you feel this is still a valid issue then please comment, or create a new ticket following the Issue Guidelines.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Feedback – 📖 Game Wiki
This can also happen when holding the sneak button while leaving water, touching water (MCPE-39970), closing a menu (keyboard), and flying in creative mode, as well as changing dimensions (keyboard) and pressing movement keys just before loading a world.
This also happens when you lock crouch down by pressing shift+alt - you stop crouching when opening a chest or menu, and you have to double tap shift to crouch again.
@Mega_Spud why it this a "Won't fix"?
To add to the ticket, having to reclick mouse 1 to mine/place in bedrock edition after scrolling to change items is really annoying, especially when it works fine in Java Edition no problem. It also works fine in bedrock edition if you change with hotkeys, but not with the scroll wheel. This inconsistency is a bug.
Also, I recognise that this is a slightly different issue, but there is nothing fun about having to spam click when you want to mass breed cows to farm leather or power level (this is just one example, I'm sure there are others). Again, holding mouse 2 worked fine in the Java edition. This is also quite a major accessibility issue, for example the game 'The Long Dark' allows you to toggle on an option to hold down buttons instead of mash them in quick time events, for the sake of players who find may find this physically difficult to do.
Having to click so much over a long period of time carries a risk of physical hand/wrist injury through RSI, and generally makes the gameplay experience worse for everyone, not just people who may have difficulties. I have raised a feature request for this, but I think it quite likely that this issue and the issue in this bug ticket are linked.
@Doubletoad74
I raised it at https://feedback.minecraft.net/hc/en-us/community/posts/360076318792-Allow-users-to-hold-down-input-instead-of-having-to-spam-click-press but it looks like someone has deleted it 😞
The general idea was that any action that needs repeated inputs should at least have some sort of accessibility option to allow the user to hold to the input instead. I argue that this would make the gameplay experience smoother and more enjoyable for everyone.
I loaded up the Java edition, and these problems are indeed not present there and you can hold inputs for repeated actions like building and mining without issue, so maybe a 'feature' request is inappropriate. In which case, this makes it an active bug, and makes it even more confusing why this ticket has been set as a 'won't fix'.
@Doubletoad74
I'm happy to write down some clear steps on how to repeat the various bugs associated with this issue if you would like, but I think OP did a good job of highlighting all the major problems.
Never really noticed this issue.