Click or right-click stuck on OS X

You are essentially left- and right-clicking at the same time, so you will break the block you are pointing at and try to place a new one.

Doing as I said and letting go of both buttons, the affect will still continue (for example, digging down, letting go of the buttons, it will still continue digging down).

Okay, reopened. Please do not clone tickets in the future. If we believe the issue is actually not resolved, we will open up the ticket. The clone will just be trashed no matter what the case.

I get this problem too, it's really annoying! I can't even build without accidentally auto-breaking. This needs to be fixed.

It's not just breaking blocks, it's also placing them. Often when I try to place a block, it just starts spamming blocks everywhere, even when I release all buttons. It acts as if left click or right click is being held down even when it's not. Makes it very difficult for me to play.

I'm constantly affected by this as well. Seems to happen more often with the MacBook Pro trackpad, but it also occurs way too often on my iMac with a Magic Mouse. As described by James Asbury, I too get the breaking and placing blocks, and it happens in Creative or Survival modes. And yes, the behavior continues even if my hand isn't on the mouse...just breaking more blocks.

Relates to MC-13695, specifically this comment by Grum:

"Fixed". I've hacked some rudimentary support for this into the game and tested the usual suspects of stack-splitting, single-item-dragging.
Side-effects:
1) Anything that use CTRL before now exclusively uses CMD on osx. (Meaning the default stack-drop-keybinding will quit your game 😃)
2) Wonky button-states when releasing a 'fake'-rightmouse press.
Obviously bugs reported against those two issues will be pointed straight here 🙂

The bug here would be a result of the "wonky button-states".

So it seems to be a common issue- but no work around to fix it?

Since it seems as if I've commented on a duplicate bug description (even if that description was better), and that one was closed, I'll copy my comment here:
I have the same problem using my MacBook Pro with a touchpad. First the ctrl-click was removed at 1.6 (how did that even happen?), and then when that issue is "fixed", we get another issue, also rendering the game unplayable.
I must say that I am kind of surprised. Surely there must be someone at Mojang testing the games with a MacBook Pro without mouse? Or is that configuration unthinkable?

This is an insane bug and I can't believe it's still here. Come on, really.

I think it may have been fixed occurring to the Grum quote a post or two above. ^^

Not fixed - that quote doesn't solve the issue for me

First: The original issue (removal of ctrl+click = right-click on Mac) was caused by a change in LWJGL. Previously, when it received a ctrl+click on a Mac, it told Minecraft that it had actually received a right-click. Minecraft never saw the control key, or the click. Just a right-click. The new launcher updated LWJGL, and in the new version, LWJGL sends the ctrl+click, instead of the right-click. So what was previously something the Minecraft code didn't even know about, or have to do anything about, became an issue.

Grum worked up a hacky fix that detects you're on a mac, and tries to treat ctrl+click as a right+click. But it occasionally produces "wonky button-states". And according to Grum:

There is no sane way around it, this has to be implemented a lower level.

He's done what he can to make this work. A better fix is going to have to come from LWJGL, and conveniently, there's already an issue open on their tracker about it. Make your voice heard there.

Also, if you've changed the binding for button 2 (as this issue states: Assigning the Ctrl key to the "Use Item" control), then I suggest you clear it. You can delete the entire options.txt file and let it regenerate, or just change these lines:

options.txt

key_key.attack:-100
key_key.use:-99
key_key.pickItem:-98

That should enable Grum's hack to do its thing properly, and cause fewer of the scrambled key events that are causing this particular issue.

Well, the sane thing to do would be to put in a bug fix in the LWJGL directly then. And since I assume you're not going to roll out the latest version of LWJGL as soon as the problem gets fixed there, really the bug should be fixed in the "Minecraft" branch of LWJGL that you are shipping with Minecraft.

LWJGL is open source after all.

The description of this report is incomplete. MC-26407 has a more complete description. It also applies not only to creative, but to the other game modes.
I highly doubt there is no workaround possible at a high level. It's easy to recognize flags using the Carbon framework in OS X, and I have never had issues with it.
Why does the temporary fix cause Minecraft to believe ctrl+click remains pressed after it has been released? Because this is the deal. Again, I think MC-26407 's description is way better than this one's.

I'm not aware of a bug in Apple's frameworks that incorrectly prolongs key presses. So the flaw must reside in the fix. It would perhaps be of interest knowing how the ctrl+click gets currently recognised.

@@unknown: So you're suggesting Mojang dig into an unfamiliar, low-level codebase and try to implement a fix, rather than the people who already know the code? How would that be the "sane" thing to do? They use LWJGL because they didn't want to deal with something that low-level in the first place.

@@unknown: They don't do separate builds of the PC version of Minecraft for each OS. It's Java, that's the whole point. The bootstrapper (not even the launcher, just the thing that loads the launcher) is the only native code in Minecraft that Mojang wrote. The rest are libraries. The primary library that Minecraft uses is LWJGL, which stands for Lightweight Java Game Library. It handles things like graphics and input. The Minecraft code pretty much doesn't know what OS it's running on, and doesn't care, and Mojang likes it that way. They don't and won't directly access the OS for input – that's what libraries like LWJGL are for. Pretty much the only OS specific code is for determining and specifying a reasonable storage location / user folder.

This bug was caused by a change in LWJGL, and Mojang's limited workaround for that change. In several of these tickets, including MC-26407, there's mention of changing the keybinding for "Use Item" – don't do this. It most likely conflicts with the workaround, and is probably what's causing the problem people are experiencing. It could also have to do with the order people are pressing and releasing control and the mouse button / trackpad.

@Torabi
What do you mean by "there's mention of changing the keybinding for "Use Item"" ? "Button 2", aka ctrl+click, should act as a right click, so binded to "Use Item". What's the point in having a workaround in the first place if this wasn't the case? Most Mac users don't have a right click option.
I inserted it in that report's description to clear out doubts, although it wasn't necessary as it probably is already set by default.

I doubt the order of press has anything to do with this problem. The command ctrl+click gets correctly recognised, but incorrectly managed/released, if at all.

As for Mattias comment, I agree. I buy a product from Mojang, and if there are problems, it's up to Mojang to solve them, in a way or another. It's not up to me to solicit fixes to third parties. I don't care about what libraries the game uses - I care about the product that I buy. The company that produces the game is responsible for the libraries used.

Some people have reported that they were unable to change the keybinding for "Use Item" back to "Button 2", that the controls screen would not recognize a control+click as a right-click, and would instead just assign the control key by itself to use item. On this very issue, the reporter indicates that's what happens. I don't know exactly how Grum's hack works, or at what level, but there's a distinct possibility that assigning "Use Item" to anything other than "Button 2" will cause conflicts with that hack, particularly if control is the key assigned. The game may then be receiving multiple press and release events, out of order. Under that configuration, it may be firing a press event when the user holds control, another press and a release event when they click the mouse button, and then another release even when they let go of control. It should not normally be possible for the paired press and release events to overlap like this, and may cause the sticky right-click problem reported in these issues.

This is why I suggested people check the options.txt file to ensure that the correct codes are assigned, rather than rely on the controls screen. This was brought up by other users in the comments for MC-13695.

@Torabi
This bug has nothing to do with Minecraft being unable to recognise ctrl+click as "Button 2", or as key code 99. This was reported in separate reports, and has already been fixed.

The bug we are discussing about deals with "Button 2" commands not getting released.
Ctrl+click translates correctly to "Button 2" (key code 99), but it won't get released. It gets triggered correctly as expected, but it remains active.

Checking options.txt is useless, as "Button 2", or right click, is always linked to that key code. For reference: http://www.minecraftwiki.net/wiki/Key_codes

Just to clear out doubts, you stated "possibility that assigning "Use Item" to anything other than "Button 2" will cause conflicts with that hack". The problem is that "Button 2" set as "Use Item" doesn't work as expected. So the "hack" used isn't producing the desired effect. There is no mention of conflicts with other key bindings.
Again, MC-26407 provides a better description.

It is unclear in the orignal post and in the replies what exactly the issue here is. Is it that when the control key is assigned to do something, then control clicking to right click sticks?

I ask because it always sticks for me even when the nothing is assgned to the control key.

I filed a report which seems to have been incorectly marked as a duplicate of this one.
https://mojang.atlassian.net/browse/MC-38262

Relates to MC-31158, where I mentioned this also affects block placement. Can really be a pain when firing a bow, hope they fix this soon.

Should be fixed with the new LWJGL version.

fixed at last yayy 😃

Yay! It's playable again! Nice work!