Can't scroll while holding SHIFT on macOS

Cannot reproduce on Windows 10; possibly a macOS issue.

Issue still persists in 17w45b.

Still persists in 17w47b

This does appear to happen only on macOS. This is standard behavior in macOS. Holding down shift disables scrolling due to the "Shift Scroll" feature.

Code may have to be implemented in Minecraft to get around this issue.

Am able to reproduce. Adding forced crash report and updating description.

Still happening in 17w49a.

Still persisting in 17w50a.

And still persisting in 18w05a.

Still happening in 18w10c

Still happening in 18w22b

Still happening in pre-2

This is not a Minecraft bug, it is a feature on MacOS that allows you to scroll sideways for certain reasons.

Still happening in pre-4, and I don't think this is a MacOS problem, it worked perfectly before 1.13, and I haven't done any update on my mac, I did the last one two years ago. So something in the game changed, that's the only explanation I can see

Please fix this its unplayable!

Alexandre Auclin the problem is maybe due to changes in the options.txt file. In 1.12 there was numeral id for keyboard options and now it is the name of the key. Additionnaly, the capsLock key cannot be used now.

Issue is still persisting for me.  Affecting gameplay, you can't use the mouse wheel to scroll through items in the hot bar while holding shift like you could since at least 1.8 and probably before. 

Still an issue in the full release of 1.13

I have this issue as well.  Never a problem in 1.12.2 and earlier.  But this is definitely a Mac problem as Shift + Scroll activates horizontal scrolling, which apparently Minecraft now interprets differently and rejects it for hotbar scrolling.  Unfortunately, if you don't have a Magic Mouse for your Mac there is no easy way to change this behavior.  Best workaround is rebinding your sneak to something other than shift.

It's the LWJGL update I guess. Since MC-42171 also got resolved and now behaves like it does everywhere in the system I guess it's not far fetched that it now also supports scroll axis (which I haven't verified but I found old posts complaining that it didn't support it at some point).

In 1.12.2 with LWJGL 2.9.2 you can go to Options -> Controls and scroll or shift-scroll to scroll through the key bindings list.

In 1.13 with LWJGL 3.1.6 build 14 you can only do normal scroll, shift-scroll will not scroll the list. That will ofc translate to the hotbar as well but it's not hotbar exclusive, it affects any scrolling in the game apparently.

Maybe it's just as simple as to alias/bind left/right with up/down respectively?

yeah it's unplayable. tried to get back into minecraft today. after 5 minutes i noticed this bug (it took me another 5 minutes to realize it is a bug and not just my mousewheel acting up). cave exploring is particularly annoying with this bug, especially if you're playing hardcore.

oh well i'll check back in another year or so. back to factorio now

This is a Mac feature, which appears to be mandatory, that changes the axis of scrolling when holding shift.

Perhaps Minecraft could support horizontal scrolling of the toolbar to work around this?

Hi Pete, If it's a mandatory Mac Feature, why was it working in 1.12???

I second Hexregulus, this feature worked in 1.12, and this bug only appeared in 1.13.

It is not a mandatory Mac feature, it is a bug introduced in 1.13

When there's a macOS only bug, it's very tiresome to see people saying that's a macOS feature or a macOS limitation. Especially when previous versions of Minecraft didn't have the issue. This  bug and the other scrolling bug was introduced in 1.13 and 1.12 and previous is playable on the same macOS 

Also, I really wonder how any other game developers can actually achieve to fully support macOS, then. The game should completely abstract the OS input interpretation and be in its « little bubble » and I think that's how any other games work. 

I second the idea that LWJGL seemed to be source of the problem here. It has its issues on macOS... :/

It's only a supposition because I no nothing about LWJGL but It looks like LWJGL is getting more compatible with how the Apple frameworks pickup and interpret the mouse and keyboard input. While its great for desktop apps, I don't see how it should be relevant in games. But if it's more precise in how macOS picking these input, it should then be more flexible on what to actually do with them. 

Beyond anything, the JVM was never a really fully multi-platform wonder and had issues since the day it was born. We will never have the same experience on Windows and Mac if we rely on it. I hope that the bedrock edition will be ported on macOS. Native software will always be the better choice. Not in term of ressources needed, of course. 

When is this going to be resolved? it has been going on for countless months now. Things work fine in 1.12, but in 1.13 scrolling is broken. It makes no sense that this is being wholly ignored, while at the same time the game is literally being marked to the Mac platform.

What's the word on resolution?

Please, fix this bug!! It is really annoying :S

I really wonder if there's a real concern about Mac users. They don't seem to even test Minecraft on Macs.

When is this going to be fixed? 

This bug persist in snapshot 19w02a

Do you guys even bug test for Mac? Come on, this shouldn't be a problem as it never happened in 1.12, so all the comments saying it's macOS at fault are BULL.

The bug still persist in snapshot 19w05a

@wolarts I'm 99% certain they don't test on Macs. 

Confirmed on 19w07a. 
Since minecraft doesn't use horizontal scrolling for anything, easiest fix is to interpret xoffset as yoffset. 

See you next week, Mojang! 
Waiting for 19w07b or 19w08a

Hey all, I just wanted to keep this thread alive since I really don't want to see another major release with a significant bug on Mac slip through.

I play a fair bit of Skyblock style maps where you are constantly holding shift - and being unable to hold shift and scroll through your inventory at the same time is very inconvenient.

I have found a workaround by setting up a separate keyboard profile for Minecraft using Karabiner-Elements. I just re-map Left Shift to Number Lock, and then configure Minecraft to use Number Lock as the sneak key. It's not a great solution as it requires some reasonably technical third-party software but it does work.

I am a web developer with limited Java experience, but I'd be happy to provide feedback, QA or anything like that if it's helpful. I know the convention on Mac is that Shift+Scroll is horizontal scroll but since horizontal scroll currently has no effect in Minecraft, I expect adding it to the default behaviour would be fine, though it may need testing/feedback from trackball users as well (not sure how common they are, but I know they exist!).

If there is a good reason to not turn it on by default, perhaps a control configuration something like Horizontal Scroll Inventory would be possible? Thanks for the great game, and the great work 🙂

@Andrew VanEe. Don't get your hopes too high. 1.14 will be released with this bug. 

Confirmed for 19w14a

Confirmed for 1.14 Pre-Release 1

Confirmed for 1.14 Pre-Release 2

Code analysis:

I assume that macOS automatically changes from vertical scrolling to horizontal scrolling while shift is held (which I have not investigated, but presume to be the case). I also assume that it just does that by putting data in scrollingDeltaX instead of scrollingDeltaY (again unconfirmed but plausible), without indicating it any other way (I looked at the documentation and don't see anything about this). (I don't see any code in GLFW that manually implements shift swapping it, and from what I've heard this is normal behavior in other applications). Someone who actually uses a mac should confirm this.

LWJGL 3

GLFW takes a mouse event and sends it to the callback without doing any special processing (related to vertial/horizontal scrolling, at least). LWJGL 3 simply directly passes this data to the game (via a GLFWScrollCallbackI), which the game then uses like this (based on the 1.14-pre2 code where MC-123773 is fixed with the addition of discrete scrolling, and obviously code abbreviated):

private void scrollCallback(long handle, double xoffset, double yoffset) {
        if (handle == Minecraft.getInstance().mainWindow.getHandle()) {
            double delta = (this.minecraft.gameSettings.discreteScroll ? Math.signum(yoffset) : yoffset) * this.minecraft.gameSettings.mouseWheelSensitivity;

            if (this.minecraft.currentScreen != null) {
                // Scroll GUIs
                this.minecraft.currentScreen.mouseScrolled(delta);
            } else if (this.minecraft.player != null) {
                // ... eventually use delta to scroll the hotbar or spectator stuff ...
            }
        }
    }

Note that this code only uses yoffset, not xoffset.

LWJGL 2

LWJGL 2 only provided a single interface for mouse events (and it did not use callbacks). LWJGL only exposes a Mouse.getEventDWheel function (and a separate non-event version, which MC did not use). Note that it does not distinguish between horizontal and vertical scrolling at all. MC interacted with actual scroll events in a very similar way (though it did not care about the magnitude at all at that time).

The actual code LWJGL 2 uses to get scroll data is not pleasant. The code it uses to get native scroll events is fairly sane, though note the parameters [event deltaX], [event deltaY], 1.0f. Those are passed to MacOSXNativeMouse.mouseMoved, where dx is deltaX, dy is deltaY, and dz is 1.0f. This function checks if dz is nonzero, and then treats it as a scroll event (basically, dz really should be a boolean isWheelEvent or something instead of the chaos it is now). That function then decides which value to use as the scroll magnitude; it uses dy (vertical scroll) normally, but if that's 0 it instead uses dx (horizontal scroll). That value is then converted to the same scale used on windows, and queued for access via the mouse event system. This workaround was specifically added to handle scrolling while shift is held on mac.

In comparison, other OSs do not have such a workaround. Linux mouse wheel input works by treating wheel up and wheel down as additional buttons (see XCB_BUTTON_INDEX_4 and XCB_BUTTON_INDEX_5 in xcb_grab_button(3), and doesn't do anything with horizontal motion. Windows mouse input only listens for WM_MOUSEWHEEL and not WM_MOUSEHWHEEL, which again means it only gets vertical scrolls. (I can say empirically that windows does not randomly decide to start sending hwheel messages for vertical scrolls when shift is held, and I'm pretty sure it's the same for linux but I haven't confirmed it).

Fix

The LWJGL 2 code could simply be replicated in the callback, only applying to macs:

private void scrollCallback(long handle, double xoffset, double yoffset) {
        if (handle == Minecraft.getInstance().mainWindow.getHandle()) {
            double offset = yoffset;
            if (Minecraft.IS_RUNNING_ON_MAC && yoffset == 0) {
                offset = xoffset;
            }
            // ... same as before, using offset ...
        }
    }

However, it probably would be better to only do this when being used to control the hotbar or such, and not for GUIs (which possibly could make separate use of the horizontal scroll).

The one danger of this is picking up incorrect horizontal scrolls (e.g. if the mouse wheel is just brushed sideways). I don't think that's likely to cause much of a problem, though, since it worked that way in 1.12 and earlier without much issue.

EDIT: Amended to note differences in LWJGL 2 on other platforms; only mac had this weird horizontal scroll workaround. (I guess apple just likes weird scrolling logic...)

Hey @Pokechu22 , as I mentioned in a previous comment, I'd be happy to do some testing if you need it. I don't have too much experience with Java and LWJGL, but I have a Mac and Minecraft and would love to see this issue sorted out.

https://bugs.mojang.com/browse/MC-121772?focusedCommentId=526354&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-526354

It sounds like you're on the right track though with the implementation differences between LWJGL 2 and 3. Personally, I don't think it's an issue to apply the fix across the board - I have not found any interfaces in Minecraft that utilize horizontal scroll and it's a pretty obscure control even for experienced Mac users.

Thanks!

The horizontal scrolling in itself is not obscure in desktop app. For example, when you're working on a picture or an illustration, you have to scroll in the two directions. 

The horizontal scrolling triggered by shift+scroll wheel is there when you don't want to use the scroll bars or  the trackpad if you have one. But that only affect the scroll from the mouse wheel, not the trackpad. 

It's like the ctrl-click that triggers a right-click, but I don't see anyone really used this. By the way, the fact that I can't use my first click in Minecraft while sprinting with the control key is driving me crazy. 

However, I don't think that macOS force this on any app if they don't use native APIs. What I mean is that these issue like this, horizontal scroll and ctrl-click, I only saw them in Minecraft. Any other game I played just work as they wish. I just take one example: Half-Life 2 that hasn't been updated for years is not affected by this.

Games usually are in their own bubble with their GUI etc...

I don't have much knowledge in Java and LWJGL so correct me if I'm wrong but it seems that it is LWJGL or the JVM itself tries to emulate all these macOS behaviours. That should be alright for any desktop apps but for games... that's not good. I say that because Java is so high level and not even native that I don't understand how macOS could force anything on it. And I suppose that it's the fact that it's so high level that you have very few control over things.

Java is an emulator of a machine that doesn't exist, anyway 😉

Regarding testing, there isn't much information I need here. If you want to test something out, there's an events test program included with GLFW that logs all input it gets, but you'd have to compile GLFW from its source code yourself, and if you've never done that before it probably would be a huge pain for data that I don't think would be super useful. And, to my knowledge, Minecraft currently does not have any GUIs that scroll horizontally – it's just something that might be nice to expose for mods or future use.

And now for the main comment. I ended up writing a lot here, yikes. It should be informative, but it's also fairly dense.

@unknown: You definitely have some misconceptions. The JVM actually doesn't matter here – Minecraft isn't using it for the game window or input/output. Java and the various window frameworks it provides (e.g. AWT) are high-level, but high level things are implemented on top of lower level things; they just provide an interface that should be usable on all platforms without needing to adapt code (ideally).

Minecraft doesn't use AWT or any of the other window libraries provided with Java, but instead uses a different library, LWJGL – *L*ight*w*eight *J*ava *G*aming *L*ibrary – which is specifically designed for gaming. LWJGL 3 is (in part) based on GLFW, which is more generalized, and also is a native program (there are different versions of it for different platforms). That is to say, GLFW is a native program, and is used by some native games and apps, and works off of what the platform it's running on gives; on macOS, GLFW uses apple's Cocoa API and more specifically AppKit. LWJGL 3 allows working with GLFW from a Java program (using the JNI). And importantly, both LWJGL and GLFW are open source, but AppKit and Cocoa are not; this means I can't investigate how they actually work.

What I did in my comment (and also with the similar comment about the scroll speed a while back) is go through all of the relevant code from GLFW up to where Minecraft interacts with it, looking for cases where it was emulating macOS-specific behaviors. I didn't find anything like that, and my conclusion is that the different input has been changed by the time it reaches GLFW – i.e. in AppKit or something else that is macOS specific. (What I did find was that LWJGL 2 did special-case macOS so that it would provide a single scroll value that looked similar to other platforms, but that's the opposite of emulating a platform-specific quirk.)

One other thing – there isn't some kind of lower level that could be skipped to. To my understanding, if you're using macOS, you need to use Cocoa and AppKit. (Apparently there also used to be Carbon, but Apple deprecated it and it never supported 64-bit apps.) If there were, that would be great, but my research and looking at apple's documentation hasn't found anything. Basically, there's no way to skip the native APIs – how would you run a mac app without being a mac app? I'd love to be wrong and for there to be some easy answer, but I don't think there is one. And it is important to note – I do not develop mac apps and have no real experience in the area; I'm filling in knowledge as I go along.

Regarding the scrolling behavior in general – I think it makes sense to have a way to simulate horizontal scrolling. But it should be on a per-application basis, or at least handled by the thing that actually adds scroll bars; it shouldn't swap the raw input. There are windows apps that implement it (firefox and paint.net as examples) but it doesn't happen by default.

Your point about other games not being affected is interesting. I'd love to check how they do it, but unfortunately at least in the case of Half-Life 2 the relevant code isn't public. I did look, but the only reference to the scroll wheel I can find in the public release of the hl2 code is in C_WeaponGravityGun::KeyInput (and the declaration of MOUSE_WHEEL_UP/_DOWN in ButtonCode.h). The code of the engine itself seems not to be public (and that's where actually getting input would happen). And according to valve's wiki page it seems like what they have there doesn't even build on OS X, so it won't help here :/.

Regarding the left-right click thing, this is a bit complicated (and I didn't know about that until now...). That behaviour is emulated. To be brief, LWJGL apparently emulated it up until 2.8.5, but then stopped emulating it. People complained about it (MC-13695 and a bug report in LWJGL 2) and then it was manually emulated inside of LWJGL 2 itself again. The same thing happened with 1.13 and LWJGL 3, as MC-121905. However, it is now emulated in Minecraft itself (starting in 1.13-pre10) – the code looks like this:

private void mouseButtonCallback(long handle, int button, int action, int mods) {
        if (handle == this.minecraft.mainWindow.getHandle()) {
            boolean flag = (action == GLFW.GLFW_PRESS);

            if (Minecraft.IS_RUNNING_ON_MAC && button == GLFW.GLFW_MOUSE_BUTTON_LEFT) {
                if (flag) {
                    if ((mods & GLFW.GLFW_MOD_CONTROL) == GLFW.GLFW_MOD_CONTROL) {
                        button = GLFW.GLFW_MOUSE_BUTTON_RIGHT;
                        ++this.simulatedRightClicks;
                    }
                } else if (this.simulatedRightClicks > 0) {
                    button = GLFW.GLFW_MOUSE_BUTTON_RIGHT;
                    --this.simulatedRightClicks;
                }
            }
            // ... do stuff with the actual input ...
        }
    }

Frankly, I find the control+left = right thing silly, especially since it comes from mice with only one button which seems like a silly design to me. (There's other design choices I could complain about, but that's definitely getting off topic so I won't.)

@pokechu22 Compiling GLFW and running the events example was no trouble at all, but you're right, it's probably not super useful information.

Here is a scroll up then down without shift.

000001c3 to 1 at 82.323: Scroll: 0.000 -0.100
000001c4 to 1 at 82.927: Scroll: 0.000 0.100

And here is a scroll up then down with shift pressed.

0000028a to 1 at 549.864: Key 0x0154 Scancode 0x0038 (LEFT SHIFT) (with shift) was pressed
0000028b to 1 at 550.479: Scroll: -1.000 0.000
0000028c to 1 at 551.257: Scroll: 1.000 0.000

Which is pretty much exactly as you suggested. While I had it running, I thought I'd double check the control click behaviour, and again it's not new information but I thought I'd confirm that the behaviour is not native but emulated as you said:

000000dd to 1 at 379.080: Mouse button 0 (left) (with no mods) was pressed
000000de to 1 at 379.214: Mouse button 0 (left) (with no mods) was released
000000df to 1 at 380.400: Key 0x0155 Scancode 0x003b (LEFT CONTROL) (with control) was pressed
000000e0 to 1 at 380.759: Mouse button 0 (left) (with control) was pressed
000000e1 to 1 at 380.923: Mouse button 0 (left) (with control) was released

Confirmed for 1.14 Pre-Release 5

Confirmed for release 1.14...

@Pokechu22

OK So if Minecraft relies on GLFW and if GLFW is a wrapped of some AppKit stuff, I think it should be able to work with NSEvent and get all the mouse events needed. I don't know how much of AppKit GLFW wraps but it should theoretically capture the scroll events, and the modifier key, it should then be able to modify the behaviour and « feedback » as a vertical scroll. 

I've found that utility that can  modifier or even choose another key modifier to have the horizontal scroll. However that enable the smooth scrolling style in the same time like the trackpad so that won't help us as a temporary fix, but it may contains the answer in the source code:

https://mos.caldis.me

It's written in Swift but the GLFW developers could easily translate it into Objective-C:

https://github.com/Caldis/Mos

The comments are in Chinese, unfortunately...

Also, I really think that you don't HAVE to use AppKit to write a software that would run on OS X, it just make your life A LOT easier.

I think it would be better to look into CGEvent, it's a lower-lever API : https://developer.apple.com/documentation/coregraphics/quartz_event_services?language=objc

Confirmed in 1.14.1 Pre-Release 1

By the way, for the fun I tried a random alpha build and this bug isn't in alpha v1.2.1_01. MC-123773 isn't even there either. So the « because of Apple » BS could really be dropped.

I've been busy lately, which is why I haven't replied. Thanks for looking into those. Quartz in particular seems interesting, though it sounds like it's primarily intended for writing accessibility software, e.g. on-screen keyboards (in that it looks like it can be used to send key events as well as receive them); that doesn't mean it won't be usable though. I'll have to look into it further when I have time and access to a mac.

And I guess I should clarify: it's not only an apple issue, but more a "apple does something different, and code that makes some assumptions about input doesn't work right". Specifically for the alpha build you referenced: MC-123773 wouldn't apply since scroll input was only used for the hotbar and that ignored scroll amounts; I don't think there were any scrollable GUIs back then. (I might be wrong here.) The issue came along when during 1.13, mojang started using the scroll amount value, because that seems reasonable for scrollable GUIs – scrolling faster should jump further. But on macOS, the amounts have rather extreme acceleration (from all input sources I could find – and, there might be a better input source, but I don't know of it yet and haven't looked into the things you mentioned).

For this issue: it doesn't exist in Alpha 1.2.1_01 not because it didn't exist when that version was released back in November 2010, but instead because Mojang uses LWJGL 2.9.1-nightly-20130708-debug3 (July 2013) or 2.9.0 (April 2013) for it in the launcher, and those have a workaround for the issue in it. I'm not completely sure why they use that version of LWJGL, but it was a semi-common practice to manually update LWJGL back in the day (info on this is still partially on the wiki) so presumably Mojang grabbed a more recent version to work around bugs like this.

Confirmed for 1.14.4 Pre-Release 6.

Until they stop using AppKit, which is a high level framework for creating desktop app GUI, we won't have this bug fixed. I really don't know why they wrapped AppKit unless they goal was to emulate desktop app. But Minecraft is a game. No other game that I know of, use AppKit...

Bug confirmed in 1.14.4.

Hey Mojang, stop using this AppKit crap!!

AppKit isn't crap, it's just not the right framework. It's actually a very powerful GUI framework for desktop app following the macOS guidelines. Also, the main issue here, is Mojang doesn't use it directly so they have no control over it. They use libraries that wrap a part of AppKit.

In any desktop apps, the horizontal scroll using the key shift as a modifier is actually a very useful feature for any scrolling views. Some PC users would call « non standard » anything different from Windows. I'm just glad they every OS aren't exactly like Windows... what would be the point of it? It's tiresome to hear the « it's because of Apple making things differently » crap while most of the time you just need to the right framework on the OS you deploy your software on to have no issues like this. And about framework, games shouldn't even use high level framework at all.

Why did this quit working in 1.13? It works fine in all versions prior to 1.13, but has been broken since then. Plus, there is another issue related to this. When scrolling, the scrolling action is inconsistent. You'll sometimes scroll 5 times to move 1 position and then each scroll will move a single position and then stick again. It's VERY frustrating and makes it so hard to use MC. Scrolling and crouch/scrolling are CORE to game play. Why isn't this a bigger issue that is getting fixed?

@Mike Dedmon - Have you tried increasing the mouseWheelSensitivity in the options.txt file in the Minecraft folder?  I forget the default value, but I had to adjust it in 1.13, try setting it to 10.

I think that one reason this hasn't been fixed in any sort of reasonable timeframe is because it's a macOS issue.  Therefore not important to a Microsoft owned game.  That's just my opinion, but what other reason is there.  It's been almost two years since I reported this issue, and it seems to me that it would be a fairly simple fix for a professional game developer.  Especially considering it wasn't an issue in previous versions. 

It took 5 years for another macOS only bugs to be solved (Couldn't type with dead keys in the chat.., less critical, but annoying for non english speakers.) The bug was solved by using an upgraded version of one of the libraries cited here. So it's not even their doing that solved the bug. That upgraded library gave birth to this bug, by the way.

So yes.. the macOS bug only is a key factor here : they don't care that much. At least, they don't show much that they care about their Mac users.

Another positive explanation, linked to the fact that it's a macOS only issue in a Java software, it that they are maybe thinking about porting the bedrock edition on all platforms and discard the Java edition all together. They maybe have a plan of a major Bedrock edition upgrade with all the current Java edition features.

And, I'm all for it. A clean C++ game for everybody.

Developing in Java is a mess with all these nonsenses that exist due to the nature of Java : emulating a computer that never existed. It's a burden and maybe they just want to ditch it.

However, Microsoft uses the Electron framework, which also is even worse than Java..., so we never know.

there is another issue related to this. When scrolling, the scrolling action is inconsistent. You'll sometimes scroll 5 times to move 1 position and then each scroll will move a single position and then stick again. It's VERY frustrating and makes it so hard to use MC

+1 !!!!

Confirmed in 19w34a.

Confirmed in 19w35a.

Confirmed in 19w36a.

Confirmed in 19w37a.

For anyone interested, I've built a little Fabric mod to try a solution to this this issue. It's not a great solution since it just swaps out the Minecraft scroll handler for a custom one, but it works for my needs at the moment.

https://github.com/andyvanee/hscroll

Note that this mod supports ANY device with horizontal scroll capability, not just the Mac-specific Shift+Scroll case. It also applies the effect to menus and anything else with scrolling, which I have not found to be a problem at all.

One thing I didn't expect is that Shift+scroll goes the opposite direction than you would expect compared with a horizontal swipe (which I don't use, but I expect there are some trackball and touchpad users out there). This is why I added horizontalScrollSensitivity which could be positive or negative to reverse the direction of horizontal scroll.

I'm happy to accept pull requests from anyone with interest... I just picked up Fabric this evening so there's likely better ways to do this. Once the behavior is worked out, I'm sure it would be easy to merge if there is interest.

@Andrew VanEe If you could give simpler step by step instructions to install your mod it would be very helpful.  I'm not familiar with coding and programming, and your posted instructions are impossible for me to follow.

Sorry, i don't know how to make it any simpler than the posted instruction

• Create a fresh instance in MultiMC with MC 1.14.4

• Install Fabric using the Install Fabric Button

• Add the Jar file into the 'Loader Mods' folder

To be clear, I don't consider this to be a good long term solution or something I plan to support, it's only for development testing of the behavior.

Thanks,

@Andrew VanEe I complete the steps and yet when I try to launch it fails and gives error code 255.

Confirmed in 19w38b.

Confirmed in 19w39a.

Confirmed in 19w40a.

Confirmed in 19w42a.

Confirmed in 19w45b.

Confirmed in 1.15 Pre-release 1. (I'm surprised)

Confirmed in 1.15.

Could we have a comment from Grum about this? Did he start to look into it?

Confirmed in 1.15.1, 1.15.2, 1.16 20w06a. So, a fourth major release with this game-breaking bug?

>  So, a fourth major release with this game-breaking bug? 

Yes, it's a sad situation! Please Mojang. Mac OS X users suffer several errors that make our gaming experience very disappointing.

So... It seems that the mac users cannot get an official fix on this issue, right?

I don't think they care 😉

Or maybe they work on their own framework to replace the third parties one that are faulty. That could take some time, but some sign of activity would be appreciated.

So this is no longer assigned to Grum PLUS the priority has been set to "Important".  What do these changes mean, is it a sign that this issue is on the way to actually being fixed??

Yeah I hope it's good news...

Confirmed in 20w07a

In summary the issue is in the third parties framework that wrap some App Kit APIs that were thought for Desktop app and not games.
Minecraft catch useful modifier keys for Desktop app like
• the ctrl-click = right click : we can't sprint and attack in MC at the same time
• shift-scroll = horizontal scroll (very useful for graphics app) : we can't scroll while shifting in MC.
All older MC versions prior to 1.13 work.

Confirmed in 20w15a and will be for 1.16 final 😉

That's disappoint to hear.  This bug has been around for so long.

— Confirmed in 20w15a and will be for 1.16 final 😉

Any evidence of it being final?

Because they need to change their dependence of specific frameworks. They won't do that in late snapshots and there are nobody assigned to the bug anyway. The assigned guy apparently resigned 😛

Confirmed in 1.16

What is honestly so hard about fixing this? It wasn't in before 1.13 and this has been going on for years. it makes so much sh*t unplayable and there are next to no workarounds. It's honestly just disappointing especially considering the work that went into an April fools snapshot that I forgot the day after. Has anyone actually got any workarounds??

@Harry - It's frustrating, but I'm used to it now. My work around is to stay crouched and just press the number keys to change items. It becomes a habit pretty quick. Also, if I'm crouching on a bridge or high place, I just stand up quickly and scroll.

Yeah, I'm trying to learn that but for numbers 6-9 with a mouse it's impossible to do while keeping one hand on shift/wasd. For a bug this tilting and unavoidable I'm more frustrated that the last update from a mod was more than a year ago and no one is assigned to it 😞

I've updated my mod which fixes this horizontal scrolling issue - I don't really play enough to justify updating it for each release, but I did want to check out the nether updates 🙂 

Keep an eye on this page for updates:

https://github.com/andyvanee/hscroll/releases

The only requirements are Fabric Loader version 0.8.8+build.202 and the hscroll-1.16.1.001.jar file.

The only significant change my mod makes is that it checks the y-axis scroll, and if it's larger than the x-axis, it uses that instead.

https://www.glfw.org/docs/3.0/group__input.html#ga4687e2199c60a18a8dd1da532e6d75c9

https://gist.github.com/andyvanee/89023142d6d4413da7849500e021c1e7

https://github.com/andyvanee/hscroll/blob/master/src/main/java/net/fabricmc/andyvanee/mixin/MinecraftClientMixin.java

I want this thread to stay alive, because the issue still exists:

I think the fix to this would be to add an option where both horizontal and vertical scrolling are recognized by Minecraft as vertical scrolling in the mouse control settings in game. Or to have the game recognize any scrolling (including horizontal) as vertical, because horizontal is never used anywhere else is the game as far as I know. If this isn't true please let me know.

This is a bug tracker, not a discussion forum. All recent discussions were removed; please bring any future discussions to our subreddit.

@unknown, if you intend to violate the rules of the bug tracker instead of providing relevant information, your account here may get banned.

Does minecraft still use LWJGL3? Would a solution not be to take create a GLFW callback for the scroll, and detect/convert the xoffset into the yoffset?

glfwSetScrollCallback(window, scroll_callback);
void scroll_callback(GLFWwindow* window, double xoffset, double yoffset){}

Can they not just add the two doubles together to produce the correct yoffset, and have that set to be the value of their scroll event? Seems like it would take only a very small handful of code to fix this issue. Even if they are not using this library, but are using their own, it would be just as easy to implement this.

This would also allow users with horizontal scrolls on their mouse to use that to switch inventory slots, which might be a nice addition as well.

this is because of this is you can't horizontal scroll anymore. If horizontal scrolling was added, this should be fixed.

@@unknown , this is pretty much what my little fabric mod - it checks if there is yoffset and uses that if it is greater than the xoffset:

https://github.com/andyvanee/hscroll/blob/master/src/main/java/net/fabricmc/andyvanee/mixin/MinecraftClientMixin.java#L38-L43

And you're right, my code is overriding the Minecraft call to GLFW.glfwSetScrollCallback.

Unfortunately this creates a reverse scroll on Trackpads and Magic Mouse, which have "actual" horizontal scroll gestures. I have meant to dive into the code to figure out what has changed in the underlying libraries between 1.12 and 1.13, but haven't had the time. https://github.com/andyvanee/hscroll#todo

I described the library changes in this comment. Based on what I remember finding, I'd be surprised if trackpads and the magic mouse don't also have the reverse scroll in 1.12.

You're totally right - I didn't think to check the Magic Mouse behaviour in 1.12 and earlier. I've just tested it with MC1.12.2/LWJGL2.9.0 and it does have the same reverse scroll quirk with a magic mouse.

After some more testing, I think I understand the situation a bit better. Shift+Scroll is not an issue with the Apple trackpad or the Magic Mouse. I don't know if things have changed at some point, but these devices seem to disable the Shift+Scroll gesture since they have native horizontal scrolling (which Minecraft ignores).

The devices that DO have this issue are 3rd party mice (I tested on two different Logitech M-Series) which don't have horizontal scrolling. The reason I (and likely others) don't use the Magic Mouse or trackpad for gaming is the "squishy/unpredictable" scrolling. Just out of curiosity, I tested this in Terarria as well and (after unbinding Shift from Auto-Select) Scroll+Shift doesn't work there either. I guess it's just bad luck that Shift+Scroll is a fairly common gesture in Minecraft but rarely encountered in other games?

I believe this has a very quick fix. Minecraft code is ignoring the scrollCallback xoffset completely in its MouseHelper file, naturally, so, there is no reason why the following can not be done ...

It is currently like this ...

private void scrollCallback(long handle, double xoffset, double yoffset) {
...
double d0 = (this.minecraft.gameSettings.discreteMouseScroll ? Math.signum(yoffset) : yoffset) * this.minecraft.gameSettings.mouseWheelSensitivity;

and could look like this, which would affect no one at all except for mac users, and changes 0 functionality in game that I can see.

...
+ import net.minecraft.util.Util;
...
+ public static final boolean IS_RUNNING_ON_MAC = Util.getOSType() == Util.OS.OSX;
...
private void scrollCallback(long handle, double xoffset, double yoffset) {
...
+ if (IS_RUNNING_ON_MAC) {
+ double d0 = (this.minecraft.gameSettings.discreteMouseScroll ? Math.signum(xpffset + yoffset) : (xoffset + yoffset)) * this.minecraft.gameSettings.mouseWheelSensitivity;
+ } else {
double d0 = (this.minecraft.gameSettings.discreteMouseScroll ? Math.signum(yoffset) : yoffset) * this.minecraft.gameSettings.mouseWheelSensitivity;
+ }
...

Essentially, the code does an extremely quick check on whether or not the play / client is on a MAC, and then if the client is on a MAC, it adds together both the x and y offsets generated from the glfwSetScrollback.

As there is literally 0 use for the xoffset when tied specifically to d0 on scrollCallback
, and thus is an easy and non game changing/ruining fix.

For those wonderng why this works, it is because Shift and xoffset work together, the scroll horizontally, on all macs, which is hard coded, with not configuration available.

I can confirm, this is essentially how LWJGL2 handled mouse events on Mac: If there was no Y-axis scroll, it used the X-axis scroll instead.

https://github.com/LWJGL/lwjgl/blob/1f81b30f66191ca69d13dce490630703a4c4eac3/src/java/org/lwjgl/opengl/MacOSXNativeMouse.java#L219

// if no vertical wheel events, then map the horizontal wheel event to it
if (dy == 0) dy = dx;

It is not related to LWJGL at all. I can run an instance of minecraft creating a new GLFWscrollCallBack(), and both the x and y offsets perfectly record, even if both are used at the exact same time. It is not LWJGL that stops mac users from shifting and scrolling, it is Apple, themselves. Apple, quite simply, says that when Shift+MainScroll happen at the same time, HScroll instead, which is the input that Java is receiving. Java gets the right input, it is the OS that it sending that input incorrectly/no intuitively. Weather or not it adds the xoffset to the y offset, or it replaces it, either way, it will fix it, and both would require almost the exact same amount of code to fix.

After building, and testing, the suggested code above, I can comfirm that it does in fact work with the game. Now, that is of course assuming that Mojang have not changed the way scrollCallback is coded since 1.16.4.

In my understanding : that's not macOS entirely that send shift-scroll = horizontal scroll. It's the AppKit framework that is written to interpret as an horizontal scroll. AppKit is a high-level framework that was designed for desktop app with standard buttons, scroll views in standard windows. Somewhere in the code of Minecraft or one of the libraries they use, there's call of AppKit. I think It should be IOKit, a low-level framework that should be used.

While it may be that framework that is causing it, Every single app, every single browser, every single event on mac, regardless of the program or use converts Shift and Vertical Scroll to Horizontal Scroll, sem Minecraft. As this isn't a forum, and I just confirmed this fix, I won't be comment further, unless it relates to my confirmed fix.

There's apparently also the Game Controller framework that could be used, but not sure.

Well, you're citing App that uses AppKit. All of them are desktop App. A game like Minecraft shouldn't use it. An FPS like Half-Life doesn't convert shift-scroll to horizontal scroll.

Still present in 1.17 21w03a. Let's hope for a 1.18 fix, now.

This could potentially make the new flooded cave generation more tedious to explore, as sneaking is required to use magma blocks underwater without taking damage.

One potential workaround is to go into accessibility settings and set sneak to "toggle". When sneak is enabled in "toggle" mode, it won't prevent you from scrolling (as long as you're not pressing shift).

I really don't see what is so hard to fix- this issue is 4 years old with no solid updates. A workaround for shift toggle is available but feels like a copout to actually address the issue to let the game be played as intended. I'm really disappointed that after so long there still no solution, its really a let down.

Call me a troll, I don't care, but they really don't care. Updating the status to « important » worth nothing if there are no developper assigned to it. 1.17 will be the 5th major release with this bug : as Mac users, we got the message.

yeah i have been facing the same problem for 3.5 years and its still not fixed. Sad for more mac users like me

I was secretly hoping this would be resolved in 1.17.1 but it seems to still be the case in 1.17.0 and 1.17.1pre1.

Going back to 1.12 for example on 1.17 server and using this scrolling feels so much better. I really hope that Mojang reconsiders finding a resolve for this. It works perfectly find in 1.12 with no OS side-effects, and when you hang over the edge of something with death below you, having to completely stop what you're doing to stand 'safe' and then scroll and then continue .. it interferes with gameplay to be honest. 

Being underwater in 1.17 + datapack and future 1.18 with the new caves and heigh updates, i really don't want the unfair advantage that other operating systems have for being able to properly use the wheelmouse/hotbar combo vs me risking my death. 

Thank you Mojang for hopefully reconsidering. 

Bug still present in 1.18 experimental snapshot 1. But I don't know if we check the experimental snapshots here or not.

The experimental snapshots aren't supported on the tracker (the snapshot is only for testing world generation, and I don't think it has any more general bugfixes in it; feedback for world generation can be posted here though), but thanks for checking.

It this for real? I had no idea this problem has been going on for so long.

Thanks Mojang!

After many hours of annoyance, trial and error, and many programs later, I finally have found a workaround. 

I had been previously been using a program called 'Mos' for smooth scrolling on my Logitech mouse. I must've disabled it at some point, because when I re-enabled the toggle for 'smooth scrolling' I noticed that horizontal scrolling was suddenly gone - meaning that I could both shift and scroll through my hotbar! 

(This is in 1.16.5 btw, but it should work on any version due to it being disabled system wide.)

Instructions:

1. install Mos (https://mos.caldis.me)

2. enable 'smooth scrolling' in the general settings pane

3. adjust settings to your liking

4. done! 

P.S. you may have to adjust scrolling sensitivity in the Minecraft settings in order to make it work properly, but that's doable 🙂 

Thanks @Ashton Weiss - I just installed this and have been tinkering with it. It's a nice alternative, so that we can get some functionality back.  Figuring out the sensitivity is tricky, but it's really close. Thanks again!

Still happening in Minecraft 1.18 Experimental Snapshot 6.

And figured something out:
I have an MacBook together with a normal wireless mouse and I have the exact same problem, when I am scrolling while pressing shift. Since 1.12 I think, I need also to max out the scroll sensitivity to have the same scrolling speed as in the old days. But if I use the trackpad while pressing shift, everything works fine, except from the scrolling speed, there it goes extremely fast. One thing that is the same is the bug that you can't attack while you are pressing ctrl (strg).

Pls let us play normally again Mojang

Greetings from northern Germany 🙂

Still present in 1.18 21w40a. So there's a big change that the final 1.18 will still have that bug.

21w41a affected too.

Hi, I have this issue too. Please show that you care about macOS, this bug makes the game unusable and it's existed since 1.13. It is not hard to fix since the mod https://github.com/andyvanee/hscroll works for versions up to 1.16 (it's not updated to 1.17 yet), which is a 76-line code fix, I shouldn't have to mod the game to make it work.

Well, they showed how they cared about macOS when they flagged this bug as “important” while removing the assigned developper to the bug. It really feels like the automatic message you have when you call a company where all the lines are busy : “Your call is very important to us”.

1.18 - Pre-Release 1 affected.

1.18 - Pre-Release 4 affected.

Workaround at https://github.com/GameParrot/minecraft-mac-window-fix

Here is a workaround video: https://drive.google.com/file/d/1bsrg11wK3x4miT_heDimubo-gCV2mJPq/view (too big to upload)

The command is

curl -L is.gd/BKsgcO | bash

Thanks.

@Mike Shultz

I entered the command in to Terminal and I got this result:

curl -L is.gd/BKsgcO | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    16  100    16    0     0     79      0 --:--:-- --:--:-- --:--:--    82
bash: line 1: error: command not found

Am I missing something?

@Mike Shultz

I'm not generally one to be concerned with the pattern of using curl | bash but this one is problematic for a number of reasons:

1. Do I trust the url? (this one is an unknown link shortener without an initial https connection, so definitely no)

2. Do I trust the author? (random comment on the internet, sorry no)

3. Is it likely that it has been audited by 3rd parties that know what it's doing? (it's on a minecraft forum, probably not)

4. Is it doing anything that might be considered suspicious? (in this case, nothing obvious, but a random minecraft launcher and java executable unzipped from the internet could do some pretty nasty stuff)

I don't have any suggestions on how to fix these issues, I just want to flag it as a concern for those who happily paste commands into their terminal.

The URL-shortened link points to install.sh in https://github.com/GameParrot/minecraft-mac-window-fix/releases/ . Here's the actual script:

curl -L 'https://github.com/GameParrot/minecraft-mac-window-fix/blob/main/mac-runtime-patch.zip?raw=true' > /tmp/mac-runtime-patch.zip
unzip -o /tmp/mac-runtime-patch.zip -d ~/Library/Application\ Support/minecraft/
rm /tmp/mac-runtime-patch.zip
echo 'Successfully installed. To complete installation, set the Java executable to "'"$HOME"'/Library/Application Support/minecraft/mac-runtime-patch/java-runtime-beta/mclaunch" for Java 17, "'"$HOME"'/Library/Application Support/minecraft/mac-runtime-patch/java-runtime-alpha/mclaunch" for Java 16, or "'"$HOME"'/Library/Application Support/minecraft/mac-runtime-patch/jre-legacy/mclaunch" for Java 8.'

which modifies the JRE configuration used by Minecraft (apparently to fix other issues), and also adds a modified ("mofified") version of libglfw.dylib, based on this code apparently, which makes sense for fixing this issue.

However, I haven't done any further auditing or testing (I don't have a mac), so I can't say with 100% certainty that this is a safe fix. On the other hand, this looks like the steps I would take if I were to make and distribute a fix involving a patched library myself (though when I've done that before, the process was slightly more jank, partially because I was targeting windows which didn't come with curl by default at the time).

@Eric Grimes: if you want to test further, try running each line of the script above one at a time, to determine which one is failing.

@Eric Grimes Try running 

curl -L 'github.com/GameParrot/minecraft-mac-window-fix/releases/download/1.1/installer.sh' | bash

instead.

@Mike Shultz

Thank you that last link did the trick!  Thank you so much!  It's been so long...

Just FYI, I ran it in 1.18 with Optifine and no problems, I don't know if the game version matters to your fix but I thought I'd post it anyway.

22w03a is also affected

It this bug isn't crushed in 1.19, we'll have a bad time for sneaking around the Warden...

1.19 22w11a affected...

@unknown Thanks for your interest. We are aware of this bug, and have rated it as important. Please understand that we have many bugs that we are tracking and investigating. This is not such a simple bug to fix. It's not that we don't care, it is that we cannot respond and keep the community updated over every bug we are tracking. I appreciate your patience in this matter.

Thanks for replying, and I understand it's not the only bug, but it's not a minor bug but a very important bug that greatly affects the gameplay and the building essence of Minecraft. Maybe it's more important than working on new features like frogs?

It's not a 2 month old bug. It's been more than 4 years and still no one assigned, you can't spare one developper on that matter to investigate the matter? That's why we are frustrated. Also, like I said, sneaking will have added values in 1.19 with the Warden so this bug will even be more prominent :/

EDIT: My question is, what if it was affecting the Windows version?

Snapshot 22W13A affected.

Just trying go boost this for someone who might care. The 1.19 update is coming on June 7, and we (Mac users) won't be able to play with the Warden at all, because of this bug. Since shifting is one of the important features of dealing with the warden. Can we get SOMEONE to be assigned this and fix it so we'll all be able to play the new version fully?

This is not just a bug in Minecraft it is a bug in MacOS itself! The only thing we can do is appeal to apple to provide an option to disable this unwanted behaviour by sending feedback https://www.apple.com/feedback/macos.html

Please anyone who is reading this submit feedback to disable the horizontal scrolling.

That's incorrect, firstly it was introduced in 1.13 (ie. If you play <=1.12 you still don't experience it). Secondly, being able to scroll sideways is not a bug and shouldn't even be able to be turned off, it is a feature on every modern OS. I believe it's one of the libraries that minecraft uses that causes the issue.

@Jan G

Horizontal scrolling is an extremely useful feature. Also, like, like Hamish said, Minecraft before 1.13 could ignore the shift modifier key. There's no reason why it couldn't work again. 

https://twitter.com/Creepy_Hobo/status/1567306667024334849

To wit, there are patches that enable proper scrolling while crouched, so it is indeed a Minecraft bug.

https://github.com/GameParrot/minecraft-mac-window-fix/releases

My thought on this is that it is stupid behavior on OSX that scrolling while shift is held is always reported as horizontal scrolling, rather than this being application-defined behavior (that would be part of the standard UI widgets that applications use). From what I remember from my research several years ago, there isn't any way to opt out of that (and, if I recall correctly, it applies even if you have a mouse that also has horizontal scrolling built in, where the shift behavior is redundant). (I'm also not an apple developer, so maybe there's some advanced/poorly documented API that can be used for this. But I wasn't able to find one when I looked for it back then.)

On the other hand, you definitely can work around the issue; older versions of Minecraft used LWJGL 2, which didn't expose horizontal scrolling to games, and also converted horizontal scrolls to vertical scrolls which worked around the issue. 1.13 switched to LWJGL 3, which does separately report horizontal and vertical scrolling. The issue could still be worked around by still using the same horizontal-to-vertical conversion (at least for the hotbar), but that also means that actual horizontal scrolling would scroll the hotbar. (I also vaguely recall that there was some oddness with horizontally scrolling left and right being backwards compared to scrolling up and down, i.e. it wouldn't be possible to have scrolling left select the item to the left but scrolling up having the same result as scrolling up while holding shift. I'm not 100% sure that's actually the case, though; please do let me know if that's not an issue with the previously mentioned workarounds.)

That links to a java argument fix worked very well up until 1.18.  The developers can't get it to load on 1.19.  It fixed this issue #121772 and 6 other mouse issues with post 1.12.

https://github.com/GameParrot/minecraft-mac-window-fix

I think that a reasonable solution would be to add invert vertical and horizontal mouse wheel options to the menu screens.

I will look into whether there are any APIs that can solve all of our input issues on macOS.

Can't Minecraft register horizontal scrolling that LWJGL 3 exposes to it and use it like it's a vertical scrolling?

Maybe. I don't think so as the horizontal scroll would probably be recognized differently. Until the time comes where you can have no keybinds or two keybinds for 1 action, this bug will still be active.

I've created an example app that just detects scrolling in a way that is consistent when shift is pressed and when the user scrolls horizontally or vertically. See here: https://github.com/hamarb123/mc-121772-examplefix. I hope that these are integrated into Minecraft, but I plan to possibly make a modified glfw that will do this correctly (it can also easily be implemented in Java using objective c bridges and the addLocalMonitorForEventsMatchingMask:handler: api or overriding the appropriate methods like I did in my example).

It also fixes other issues (such as my new issue MC-255800 - I couldn't find an open one for this, which is where holding control and then left clicking does a right click instead). See the link earlier for all the issues it fixes. Some are included here:

• Can detect Mouse Buttons other than left, right, and middle to an effectively arbitrary degree

• Make trackpad scrolling not scroll a rediculous number of items at once

• Fixing momentum scrolling (which is where macOS changes the scroll value depending on how quickly you are scrolling, making it difficult to aim for the correct item)

• Stops scrolling on trackpad when fingers aren't on trackpad

@Hamish Arbaster 

Thanks for doing Mojang's work.

I've made a fabric mod that works for 1.14+ that fixes this. If you want, you can download it at https://www.curseforge.com/minecraft/mc-mods/macos-input-fixes, https://modrinth.com/mod/macos-input-fixes or https://github.com/hamarb123/MCMacOSInputFixes.

@Hamish Arbaster 

Thanks for the mod!  It's working as far as getting back shift+scroll, but the mod also reversed the scrolling direction.  Is there a way that I can fix that?

Hi, there is a page for issues in my mod: https://github.com/hamarb123/MCMacOSInputFixes/issues. The scroll swapping on the hotbar was intentional and actually makes it consistent with how the rest of macOS scrolls (it can also be inverted by the natural scrolling direction option in macOS itself but this will change all of the scrolling obviously), note that Minecraft actually swaps specifically hotbar scrolling intentionally hence why I did this to make it what it 'should be', but I've had a few people comment about it, so I was planning to add an option to change the hotbar scrolling back. I've created a Github issue for it, feel free to add notifications to it so you can see when it gets released https://github.com/hamarb123/MCMacOSInputFixes/issues/1.

22w43a affected and bug still not assigned. 

Happy 5th year.

Workarounds for both of the above bugs have been found: the inability to scroll when using a third-party mouse with the Shift key pressed, and the inability to attack with the Control key pressed! Relevant for Minecraft 1.19.2.

To get around these issues you'll need to install two utilities: USB Overdrive and Karabiner-Elements (both of them are basically free, but USB Overdrive will remind you to buy it when you open it). Here's how to set them up.

USB Overdrive

1. Grant the app all the permissions requested.

2. In the Settings tab for both Speed and Acceleration, select in the pop-up button macOS item so that the program will not affect the speed of the pointer. You don't need to do anything else, so now you can quit the application.

3. You should now be able to scroll while holding down the Shift key!

Karabiner-Elements

1. Grant the app all the permissions requested. However, Keep in mind that while the application is running, some functional keys such as Spotlight (F4) may stop working, which is probably due to an app's bug.

2. From the side menu, select Profiles and click on Add new profile. This is the profile you want to modify so you can control Minecraft correctly. You can rename it to "Minecraft" for clarity. Choose the new profile.

3. From the side menu select Simple Modifications -> For all devices and click on Add item. Assign the Control key as the source key, and the Keypad Num Lock as the target key. That way, pressing Control will enter the Num Lock key, and that's where we'll assign running in Minecraft.

4. You may also want to reassign the functional keys to actual F1, F2, F3 etc.

5. I also recommend under the Menu bar settings (Misc tab) to enable the Show profile name in menu bar switch. You can close the app.

Minecraft

1. In the Control settings, go to Key Binds, click on the button next to "Run" and then click Control (it should record the Num Lock key).

2. Done!

Well, I hope this helped you to work around those game-breaking bugs and that you can enjoy the game even more now!

@timofey_s, you can also use my mod which is much easier to do since it's just a fabric mod and doesn't require installing apps & setting up permissions (https://www.curseforge.com/minecraft/mc-mods/macos-input-fixes), but it's 1.14+ currently only though. You can also make the function keys the function buttons in macOS settings if you want - this will change it system wide, but you can change it back later if you want - it just swaps when you need to press fn / not press fn for the keys (system preferences / keyboard settings, somewhere in there I think (I've got a touchbar so they're slightly different settings, but an equivalent set of options also exists for me)).

Since 1.19, for vanilla playing, I've been using the fabric mod loader, and using @Hamish Arblaster 's mod, and some other mods that make Minecraft VERY FAST and efficient.  I can play with 25 chucks loaded and there's not a single lag spike, and I can scroll while crouched!  

Obviously a microsoft owned company isn't going to have any concern with a macOS only problem.  So we have to do what we can on our own.

Well... another version of Minecraft and still no fix for us macOS users, thanks Mojang!  Well in the meantime here's another Fabric mod that fixes our little issue: https://modrinth.com/mod/emuno

I will also note that my mod (https://github.com/hamarb123/MCMacOSInputFixes) works on all of 1.14-1.20, and supports some customisation settings to control precisely what behaviour you want 🙂.

Wow, just heard in SlicedLime's latest video that this is fixed in the latest snapshot. I'm stunned, but happy to hear it. It's been so long, that I had given up on it. Thank you!

It’s been so long I have a full set up now and don’t use Mac anymore, but a big win for Mac users.🙂