Looks like we have unicorn in the wild, boys. More evidence of hardware issue on the new MBP's, coupled with the issue persisting on Ventura by @vreedom
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Tap-to-click issues on B9 and 10 (and now Monterey release)
- Thread starter Cozmosis
- Start date
- Sort by reaction score
It's not a hardware issue, you can try it on the magic trackpad as well, they tweaked the dead-zone. The magic trackpad dead-zone seems about right though in that's it's less than a finger-width from the edge (although this is still larger than what it was < 10.8, there you can basically get right to the edge without issue). For inbuilt trackpad it's about a finger and a half width which is too large and it's causing the issues of dropped tap-to-click at the edges.
Note that this is just a guess based on experimentation, I'm not going to dig into the MultitouchHID kext again to find the codepath responsible for this because I don't use tap-to-click on inbuilt trackpad and it's not going to be useful to anyone anyway since probably no one wants to disable sip and patch things. Plus I already gave a suggestion of how you can work around from userspace using your own frame callback and post click event yourself after a tap (and do it better than apple, because you can actually do palm rejection right).
This isn't the first time they messed up the dead-zone width though, but I'm surprised they haven't fixed it yet because if it's like the last change the check is done in one "isBlocked" function and it's literally just comparing against edge-zone bitmask. I think it might even be intentional because everyone complained the new trackpad was too large, and this is the laziest way they could think of fixing it.
I'm just pissed because pinch-zoom is broken as well and recreating that from userspace is too tedious that I don't really want to do it. I mean I think it's basically the same formula, use an event callback and post the fluid zoom event, but then I need to write an entire gesture recognition library to properly recognize two-finger pinch zoom and correlate that to zoom state. Seems like too much effort compared to giving the thing a whack every time (read: disabling/enabling pinch zoom, which I've hooked up to BTT). If someone happens to already have that portion written or wants to write it, please let me know... (btt dev probably has gesture recognition library, but I don't think he's willing to open source it)
Edit: Aha seems like based on post on https://community.folivora.ai/t/script-to-reenable-trackpad-zoom/7669/6 there's already hidden flag BTTAutomaticallyRefreshPinches to do this. Now I wonder how it works..
And it's called in the following places:
* [delegate applicationDidFinishLaunching]
* [BTTActions init]
* nonInterceptingDragCallback (called by CGEventTap whenever mouse drag operation)
* allCB – which as the name implies is basically the master method for a ton of different event taps (I see "gestures, spotify, chrome, withoutgestures, mousemoved, scroll, normalmice).
Well that's a bit disappointing, basically same way I was doing it. Guess there's no magic sauce after all, it's bodging all the way down. Seems a bit wasteful to refresh it on every action imo, but I guess it works? Also interesting since I saw that a 0.5 sec delay was needed between setting old val and setting new val in order for it to work.
Edit 2: Another thread about this: https://community.folivora.ai/t/anyone-having-issues-with-pinch-to-zoom/2591/14 seems like it's actually not a MultitouchHID issue per se but cause by things using cgeventtap. I wish radar was public so I could see more bug detail. My best guess is that due to whatever bug this is, the zoom event does indeed get generated, goes through the normal event tap flow, but somehow gets swallowed before being delivered. What a stupid bug, and one that has 0 documentation online, up until now I was thinking it was at the multitouchhid event-generation level but seems like I was wrong, it gets swallowed later on.
So to recap, seem to be 2 ongoing trackpad issues:
* Tap-to-click not working on edges. My best guess is apple botched dead zone here, needs further investigation. Workaround is relatively easy to do from userspace, but too lazy to do it myself.
* Pinch-zoom stops working. This isn't a trackpad related issue, it's caused higher-up in the stack and is triggered when process has a cgeventtap intercepting events; according to BTT dev, events get swallowed somehow. Hypothesis seems reasonable to me I suppose... although I've never had synthetically generated fluid-zoom events get swallowed though, so I'm still not 100% convinced.
Note that this is just a guess based on experimentation, I'm not going to dig into the MultitouchHID kext again to find the codepath responsible for this because I don't use tap-to-click on inbuilt trackpad and it's not going to be useful to anyone anyway since probably no one wants to disable sip and patch things. Plus I already gave a suggestion of how you can work around from userspace using your own frame callback and post click event yourself after a tap (and do it better than apple, because you can actually do palm rejection right).
This isn't the first time they messed up the dead-zone width though, but I'm surprised they haven't fixed it yet because if it's like the last change the check is done in one "isBlocked" function and it's literally just comparing against edge-zone bitmask. I think it might even be intentional because everyone complained the new trackpad was too large, and this is the laziest way they could think of fixing it.
I'm just pissed because pinch-zoom is broken as well and recreating that from userspace is too tedious that I don't really want to do it. I mean I think it's basically the same formula, use an event callback and post the fluid zoom event, but then I need to write an entire gesture recognition library to properly recognize two-finger pinch zoom and correlate that to zoom state. Seems like too much effort compared to giving the thing a whack every time (read: disabling/enabling pinch zoom, which I've hooked up to BTT). If someone happens to already have that portion written or wants to write it, please let me know... (btt dev probably has gesture recognition library, but I don't think he's willing to open source it)
Edit: Aha seems like based on post on https://community.folivora.ai/t/script-to-reenable-trackpad-zoom/7669/6 there's already hidden flag BTTAutomaticallyRefreshPinches to do this. Now I wonder how it works..
Code:
if ([[**_NSApp delegate] runningOn_10_12]) {
instance = [NSClassFromString(@"MTTGestureBackEnd") sharedInstance]
oldVal = [instance twoFingerPinch];
if (oldVal > 0x0) {
[instance setTwoFingerPinch:0x0];
[instance setTwoFingerPinch:oldVal];
}
oldVal = [instance multiFingerPinch];
if (oldVal > 0x0) {
[instance setMultiFingerPinch:0x0];
[instance setMultiFingerPinch:oldVal];
}
}
return;And it's called in the following places:
* [delegate applicationDidFinishLaunching]
* [BTTActions init]
* nonInterceptingDragCallback (called by CGEventTap whenever mouse drag operation)
* allCB – which as the name implies is basically the master method for a ton of different event taps (I see "gestures, spotify, chrome, withoutgestures, mousemoved, scroll, normalmice).
Well that's a bit disappointing, basically same way I was doing it. Guess there's no magic sauce after all, it's bodging all the way down. Seems a bit wasteful to refresh it on every action imo, but I guess it works? Also interesting since I saw that a 0.5 sec delay was needed between setting old val and setting new val in order for it to work.
Edit 2: Another thread about this: https://community.folivora.ai/t/anyone-having-issues-with-pinch-to-zoom/2591/14 seems like it's actually not a MultitouchHID issue per se but cause by things using cgeventtap. I wish radar was public so I could see more bug detail. My best guess is that due to whatever bug this is, the zoom event does indeed get generated, goes through the normal event tap flow, but somehow gets swallowed before being delivered. What a stupid bug, and one that has 0 documentation online, up until now I was thinking it was at the multitouchhid event-generation level but seems like I was wrong, it gets swallowed later on.
So to recap, seem to be 2 ongoing trackpad issues:
* Tap-to-click not working on edges. My best guess is apple botched dead zone here, needs further investigation. Workaround is relatively easy to do from userspace, but too lazy to do it myself.
* Pinch-zoom stops working. This isn't a trackpad related issue, it's caused higher-up in the stack and is triggered when process has a cgeventtap intercepting events; according to BTT dev, events get swallowed somehow. Hypothesis seems reasonable to me I suppose... although I've never had synthetically generated fluid-zoom events get swallowed though, so I'm still not 100% convinced.
Last edited:
@f54da
Not sure if you meant 2 issues ongoing just from the perspective of drivers/code you were talking about.
If not - I'll fill in that my M1 MBP 2021 14" has no specific edge problems om the trackpad. The only issue that in about 90% of cases, I can't CMD+tap something - it always requires three taps.
However, I got the tip from somewhere on how you actually can affect it (not in a really good way but still):
If you start holding CMD - then move around the cursor a bit on the trackpad, and THEN you tap to click, it will work on the first try.
This has been quite reliable from my testing, although it's not a habit I want to develop. I want Apple to fix their stupid **** I mean come on this is beyond embarrassing. Having peoples computers destroyed by naive repairs. Inconceivable!
Not sure if you meant 2 issues ongoing just from the perspective of drivers/code you were talking about.
If not - I'll fill in that my M1 MBP 2021 14" has no specific edge problems om the trackpad. The only issue that in about 90% of cases, I can't CMD+tap something - it always requires three taps.
However, I got the tip from somewhere on how you actually can affect it (not in a really good way but still):
If you start holding CMD - then move around the cursor a bit on the trackpad, and THEN you tap to click, it will work on the first try.
This has been quite reliable from my testing, although it's not a habit I want to develop. I want Apple to fix their stupid **** I mean come on this is beyond embarrassing. Having peoples computers destroyed by naive repairs. Inconceivable!
You can't boot from an older OS for the new 14" and 16" M1Pro/Max's. It may have been a software issue with older model computers like M1 Air and Intel cpu's, but I'm arguing that the newer computers may have a hardware issue as well. It's not out of the question, and it certainly hasn't been proven otherwise yet. There's no operational OS that fixes cmd+tap for 14" and 16" M1 Pro/Max laptops that exhibit that issue. But here in the wild we had someone say their computer doesn't have that issue. So if there is a group of 14" and 16" M1 Pro/Max's that can't ever resolve the issue, and someone that asserts they don't have any of that issue. So it can only suggest an *additional* hardware issue may exist with those models.
Well, one the is aware of this thread and posting in it. If y'all need me to do any other troubleshooting just ask.
Apparently it's a software bug about how long you have to keep the cmd key pressed over the link for it to activate. I tested it and it worked for me:
Hover the cursor over the link and keep command pressed for a few moments, like, one second, then tap to click, it should work. But if you (like me and most people) just quickly try to cmd+tap to open a link it will fail. That's why it works after a few tries, it's because of the countdown for it to work.
It is SUPER annoying, and I hope they fix this behaviour ASAP.
Hover the cursor over the link and keep command pressed for a few moments, like, one second, then tap to click, it should work. But if you (like me and most people) just quickly try to cmd+tap to open a link it will fail. That's why it works after a few tries, it's because of the countdown for it to work.
It is SUPER annoying, and I hope they fix this behaviour ASAP.
I think I see the issue if I try to press CMD and tap at the same time. I normally don't browse like that, but I can confirm the issue is present on mine to some degree. If it is happening for you when you first move the pointer over the link, it might be caused by Safari trying to render the tooltip at the same time as the tap.
Last edited:
I can reliably reproduce this now that I know it's time based. I guess, sadly, that is good news. If Apple would just pay attention to it and fix it.
FYI this happens with more than the CMD tap on a Safari link. For me where I first noticed it was Option tap on Wi-fi in the toolbar, which AFAIK doesn't have a tooltip.
FYI this happens with more than the CMD tap on a Safari link. For me where I first noticed it was Option tap on Wi-fi in the toolbar, which AFAIK doesn't have a tooltip.
I wonder if this was an intentional decision by Apple, borne from user-testing, to avoid accidental trackpad taps while typing, especially since its happening in conjunction with keyboard use. Looking at the position of my hands they could easily brush the the sides and upper corners of the trackpad. Maybe its akin to how the iPad ignores accidental presses at the edges of the screen, the same may be happening with the trackpad. My work Thinkpad is awful as far as my palms moving the cursor and sometime clicking; my MBP's trackpad is huge by comparison and far more likely to be under my palm.
TL-DR - "It's a feature, not a bug". LOL
TL-DR - "It's a feature, not a bug". LOL
Last edited:
If that was the situation, it doesn't work with a click on the edges, but the error is when combining with command and shift.
Apple wants you to be able to tap on the edges and use slide-in gestures work, but with the trackpad consuming so much of the palm-rests, maybe this is how they solved accidental touch issues while typing. If this is the cause, Apple isn't going to fix something they don't consider to be an issue.
Holding the cmd/option button for a period of time before tapping...interesting... can someone (with a 14" or 16" M1 Pro/Max) test this to see if it reliably eliminates/reproduces the behavior?
That's the thing, if Apple did this to avoid accidental link clicking while typing then it will never be fixed because Apple doesn't consider it broken.
Is the issue resolved if you first press CMD and then click, instead of trying to do them simultaneously?
If the behaviour is consistent then maybe? But the behaviour is inconsistent, half the time it works, half the time it doesn't.
No. Only when holding for 3+ seconds as suggested by others above would it then work, otherwise it's inconsistently broken.
Also for me it's fixed with 12.5 on MacBook Pro 14'' (2021)...FINALLY!!!!!
Last edited:
Just updated to 12.5 and the issue persists. Anyone still getting this since the update?
And did we ever identify a usable workaround? I'm an audio editor and basically my entire workflow depends on using modifiers so I'll have to return my 2021 Macbook and use my 2015 again if there isn't a fix for this. I'm flabbergasted and really frustrated.
And did we ever identify a usable workaround? I'm an audio editor and basically my entire workflow depends on using modifiers so I'll have to return my 2021 Macbook and use my 2015 again if there isn't a fix for this. I'm flabbergasted and really frustrated.