Are you running BetterTouchTool on your Mac?
I have had a few users reporting that Chrome 61 doesn't work well while BTT is running, but I'm not yet sure what's causing this weird issue.

My theory on this bug (I'm the BetterTouchTool developer, so this is all a guess):

Chrome 61 must have introduced some sort of timing logic to determine whether a click or drag event should be generated. This timing logic uses some estimates of how long the system takes to process a click event.

This logic seems to fail in a few cases, for example when the CPU usage is high and events are processed slower than usual, or when other apps like BetterTouchTool that need to intercept mouse clicks and process them add some extra milliseconds to the event processing.

BetterTouchTool uses CGEventTaps on macOS to intercept mouse clicks. However there are many other apps that also do this and Chrome should not get confused by something like this.

This is the related issue for BetterTouchTool: https://github.com/fifafu/BetterTouchTool/issues/1445

i do not have BetterTouchTool installed, but you might be right! I just realised that i have Magnet installed, which does similar things as BetterTouchTool. After quitting Magnet the problem disappears, but I still think this is a Chrome bug because it works fine in all other browsers and worked in Chrome before as well.
https://itunes.apple.com/de/app/magnet/id441258766?l=en&mt=12

Yes, as far as I can tell this issue will affect all apps that use CGEventTaps to intercept mouse-clicks. (And there are many of them).

It definitely has to be fixed on Chrome's side. I have tried all possible options to make it work with BTT, but as soon as an intercepting event tap is installed, Chrome breaks.

Thanks for Reporting Felix. 

I also have Magnet installed.  Ihave told it to ignore magnet and will see what happens\

Thanks
@richhickson

Ignorenig chrome didnt make any difference. Have now closed it to see if that makes it work better.

Unable to reproduce the issue on Mac 10.12.6 & Windows 7 with Logitech Mouse (not with track pad) as per the given fiddle. Observed mouseup and click events are called without any issue.
Seems issue with Apple Magic Mouse.Could some one from MTV team please take a look into this issue .Adding 'TE-NeedsTriageFromMTV' label for further investigation.

Please find the attached screencast for reference.

Thanks..!!

Deleted: 763642.mp4 1.4 MB

	763642.mp4 1.4 MB View Download

Are you able to share the event tap code that you use? ie; are you modifying the event in anyway?

I'm also able to reproduce it with various Logitech mice, however it's true that it's most noticeable with the Magic Mouse.

It doesn't seem to matter whether the event tap actually modifies the events. I think just registering it and using a few milliseconds in the callback to process the event will cause the issue.
I can provide a sample app tomorrow, basically this is the Event Tap:

CGEventMask clickEventMask = (NSLeftMouseDownMask | NSRightMouseDownMask  |  NSRightMouseUpMask | NSLeftMouseUpMask);
_theEventTap = CGEventTapCreate(
                                               kCGHIDEventTap, kCGHeadInsertEventTap,
                                               kCGEventTapOptionDefault
                                               , clickEventMask, theCallback, nil);

CGEventTapEnable(_theEventTap, true);
 CFRunLoopSourceRef loop = CFMachPortCreateRunLoopSource(kCFAllocatorSystemDefault, _theEventTap, 0);
CFRunLoopAddSource(CFRunLoopGetCurrent(), loop, kCFRunLoopCommonModes);
    

eirage@ can you take a look?

Here is a minimal example that let's you immediately reproduce the issue with a Magic Mouse (and also other mice as far as I can tell, but not as obviously as with the Magic Mouse).

As soon as you start the app the clicks will not work correctly anymore in Chrome 61+.

https://bettertouchtool.net/releases/ChromeEventTapBugExample.zip
https://bettertouchtool.net/releases/ChromeEventTapBugExample_source.zip

 Issue 766218  has been merged into this issue.

I'm having same problem.  Chrome essentially unusable for me---I typically have to click 2 or 3 times just to select an email message, send a message, etc.  Problem arose immediately after recent Chrome upgrade.  Switched to Safari for now but I hope this can be addressed soon.  I normally run BTT but turning that off makes no difference.  I have also tried both Magic Mouse and Magic Mouse 2 and both have the same problem.

I stand corrected---it looks like if I "disable" BTT then I still have the problem, but if I "quit" BTT then the problem goes away.  I guess it's caused by a mouse handler that's installed and even if I disable the app so that the handler does nothing at all, the presence of the handler still causes the problem.  For now, terminating BTT seems to get rid of the problem.

I can confirm this with Chrome  63.0.3221.0 and Better Touch Tool using a Magic Mouse 1.


According to BTT this is a big with chrome that's being worked on? Is that true? 

https://github.com/fifafu/BetterTouchTool/issues/1445

*clicks submit 4 times* 

Also seeing this issue:
2013 macbook pro
macOS Sierra version 10.12.6
Chrome Version 61.0.3163.91 (Official Build) (64-bit)

We wonder if this is caused by re-ordering of events caused by the EventTap. eirage@ is trying the example with capturing NSMouseMoved as well as she indicated that we are seeing a mouse move with no buttons down set in between the down and the up which clears the target node state.

I tried adding a NSMouseMovedMask to the source code example in #15. And the issue is no longer repro.
The issue is: 
When a normal event queue is: A(MouseDown) -> B(MouseUp) -> C(MouseMove with no button down)
Because BTT capture mouseDown and mouseUp, the events chrome getting become: A->C->B. 
In M61, we do clear the mousedown states when we getting a mousemove with no button down. The messed event queue cause incorrect states when we get the mouseUp.

andreas@hegenberg.me: Can BBT also capture NSMouseMoveMask to prevent this happen?

Why does this only happen in Chrome and not in any other Browser?
And why and what did u change it in M61?
It breaks with more Apps then BTT and I think many users will not be able to track this down to the tools they might use. Probably this causes problems for accessibility tools as well.

Capturing NSMouseMoves mask is not a good idea for tools like BTT as it causes unnecessary CPU usage. I think we should rather try to find a generic solution that works with all apps. As Felix mentioned this doesn't only affect BetterTouchTool but many other apps.
Do you think this is a bug in macOS?

For now I will enable the capture of NSMouseMoved to BTT in case Chrome is the active app. 

Can you raise a support ticket with Apple?

The code was changed to fix another issue in M61 that uncovered this issue. We believe that we have an illogical stream from the OS now as eirage@ described. We've only had reports of this being an issue against BTT and Magnet.

What other apps use the event trap?

I'll raise a ticket with Apple.

I can't list names but there are hundreds of apps that use such event taps. E.g. Spotify in some configurations. Almost all window snapping tools etc..

The reason why only BTT and Magnet have been mentioned so far is that I redirected many BTT users here, so this is very biased. The problem is that the issue is really really hard to track down to a single app for normal users.


Maybe it would be a solution to detect whether such Event Taps are installed and in that case revert to your old code?

This code allow one to get a list of all installed event taps:

- (NSArray *)allEventTaps {
    
    NSInteger preCount = [self allEventTapsCount];
    CGEventTapInformation *list = (CGEventTapInformation *)calloc(preCount,
                                                                  sizeof(CGEventTapInformation));
    uint32_t postCount; // should always equal preCount
    CGError err = CGGetEventTapList((unsigned int)preCount, list, &postCount);
    if (err == kCGErrorSuccess) {
        NSMutableArray *returnArray = [[[NSMutableArray alloc]
                                        initWithCapacity:postCount] autorelease];
        int i;
        for (i = 0; i < postCount; i++) {
            NSDictionary *info = [NSDictionary
                                  dictionaryWithObjects:[NSArray arrayWithObjects:[NSNumber numberWithInt:list[i].tappingProcess],[NSNumber numberWithLong:list[i].eventsOfInterest], nil] forKeys:[NSArray
                                                                                                                                                                                                    arrayWithObjects:@"tappingProcess",@"eventsOfInterest", nil]];
            [returnArray addObject:info];
        }
        free(list);
        return [[returnArray copy] autorelease];
    }
    free(list);
    
    return nil;
}

I don't think checking for event taps is a good thing as it creates an unpredictable web platform.

Ultimately these apps are messing with the event stream the OS is delivering. Either the apps should eat the entire event stream for the input modality or the OS should enforce a logical event stream with the interaction of these event traps.

eirage@ has found out that we can back out some of the change that would fix this issue yet still fix the old issue. However it could create new issues. Ultimately we'd like to hear from Apple for the direction that should be taken.

I know that it's not an optimal solution. However given High Sierra will be released today, Apple probably won't address this issue in any of the previous releases leaving the users with a broken Chrome on many systems.

I will release a version of BTT with the NSMouseMovedMask workaround, so this will at least fix it for some of the users.

In theory the system should already keep the order of the events, I think this must be some weird bug that for some reason has not yet surfaced in other apps.
I'll try to create a minimal example for Apple. Do you know how Chrome captures the events or can you point me to that code? (Are we sure the ordering issue is not caused somewhere in Chrome?)

 Issue 769768  has been merged into this issue.

 Issue 770445  has been merged into this issue.

 Issue 769752  has been merged into this issue.

 Issue 773024  has been merged into this issue.

Don't you think it might be time for the chrome team to act? 

Why is this problem only appearing in Chrome not any other Browser/App when you say the stream of events is messed up by the OS? It doesn't make much sense to my outside view.

@andreas hegenberg: were u able to file the bug at apple? did u head anything from them? thanks a lot!

I disabled the Magnet app in OS X and the click issue seems to be resolved so this app is interfering with click actions it appears. 

I have had this problem for two weeks now and I do not use btt on my macbook pro late 2016. No issues with any other program.

I use Magnet, disabling this has appeared to fix the issue for now. Although I have only used for a short period of time. I did about 50 clicks without any failures.

We've raised an issue in Apple's bug reporting tool and are awaiting some direction of what we should do.

We are receiving MouseMove events even though we shouldn't receive them (should be MouseDrag). We can possibly discard the MouseMove events but we aren't certain what other issues that would cause.

Since I know a lot of people are coming here because of either Magnet or BetterTouchTool.

I've found that I could switch to MagicPrefs + BetterSnapTool to reproduce the lost functionality without the click bug happening.

Iam using Magnet. And Magnet is the Problem.
If i disable Magnet, Magic Mouse works like it should.

I figured out that you can disable only Chrome from Magnet. That fixed my Problem without disabling Magnet completly.

Deleted: Bildschirmfoto 2017-10-11 um 10.51.06.png 428 KB

	Bildschirmfoto 2017-10-11 um 10.51.06.png 428 KB View Download

Magnet is causing the issue for me too. However, choosing to Ignore Google Chrome in the menu does *not* fix the issue for me. Only quitting Magnet seems to work. 

Same here. Disabling Magnet seems to fix the issue with my Magic Mouse. However I would prefer to have this fixed in Chrome so I can re-enable Magnet.

I'm not using Magnet, but was still having this issue. Is this the Magnet you guys are referring to? https://itunes.apple.com/us/app/magnet/id441258766?mt=12

Quitting Magnet is the solution. Thanks. 

I use Magnet, but even if I quit Magnet, it doesn't solve the problem.

High Sierra, Chrome 62.0.3202.62 beta (64-Bit), completely removed BTT. No other tools interfering with mouse.

Yet still: Chrome is unusable. 

Any ideas?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0ffd0bb18932f2d2002218c939c3e34e13cde04e

commit 0ffd0bb18932f2d2002218c939c3e34e13cde04e
Author: Ella Ge <eirage@chromium.org>
Date: Thu Oct 19 13:47:59 2017

Do not do InvalidateClick on MouseMove

In this CL, we change reset mouse states in mouse move to
not do MouseReleaseEventUpdateStates, but only ClearDragHeuristicState.
The reason is:
1. click_count_ & click_element_ are set from WebMouseEvent on mousePress.
It won't be incorrect even if we do not receive the MouseUp.
2. On Mac(with software like BBT that trap events), event queue might
got incorrect: a MouseMove with no button down is received&handled
before MouseUp. Therefore click event will not fire since we did the
InvalidateClick() on MouseMove.

This fix won't break  crbug.com/527582 

Bug:  763642 
Change-Id: Ic278412281ba177a23b1a5fffeaa62ae123cc71d
Reviewed-on: https://chromium-review.googlesource.com/726962
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510073}
[modify] https://crrev.com/0ffd0bb18932f2d2002218c939c3e34e13cde04e/third_party/WebKit/Source/core/input/EventHandler.cpp

Tested on Canary 64.0.3245.0, the issue is fixed, and didn't bread  crbug.com/527582 . 

Your change meets the bar and is auto-approved for M63. Please go ahead and merge the CL to branch 3239 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dcf43e0c82d3031f5a78c863a7615176b2a8602e

commit dcf43e0c82d3031f5a78c863a7615176b2a8602e
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Mon Oct 23 14:31:50 2017

Do not do InvalidateClick on MouseMove

In this CL, we change reset mouse states in mouse move to
not do MouseReleaseEventUpdateStates, but only ClearDragHeuristicState.
The reason is:
1. click_count_ & click_element_ are set from WebMouseEvent on mousePress.
It won't be incorrect even if we do not receive the MouseUp.
2. On Mac(with software like BBT that trap events), event queue might
got incorrect: a MouseMove with no button down is received&handled
before MouseUp. Therefore click event will not fire since we did the
InvalidateClick() on MouseMove.

This fix won't break  crbug.com/527582 

TBR=eirage@chromium.org

(cherry picked from commit 0ffd0bb18932f2d2002218c939c3e34e13cde04e)

Bug:  763642 
Change-Id: Ic278412281ba177a23b1a5fffeaa62ae123cc71d
Reviewed-on: https://chromium-review.googlesource.com/726962
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#510073}
Reviewed-on: https://chromium-review.googlesource.com/732040
Cr-Commit-Position: refs/branch-heads/3239@{#151}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/dcf43e0c82d3031f5a78c863a7615176b2a8602e/third_party/WebKit/Source/core/input/EventHandler.cpp

 Issue 763781  has been merged into this issue.