mojira.dev
MCPE-25778

Input is unresponsive when held after changing states

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

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 12

Never really noticed this issue.

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.

2 more comments

Would it be possible for you to link the request for reference?

@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.

Why was this marked as Won't Fix? The Minecraft Feedback post was deleted...

This issue makes crossbows feel terrible to use in Bedrock Edition, also further compounded by MCPE-239075.

migrated

(Unassigned)

378877

Confirmed

Windows

accessibility, controls, input, inventory

1.16.0.68 Beta, 1.16.0.67 Beta, 1.16.0.66 Beta, 1.16.0.64 Beta, 1.16.0.63 Beta, , 1.2.0.25, 1.14.30 Hotfix, 1.14.60 Hotfix, 1.16.0, 1.16.1

Retrieved