Forgot to mention, closing and reopening the tab (cmd+w, cmd+shift+t) fixes the issue temporarily for a tab.

There also seems to be other causes for this issue, but I have not been able to produce any other reliable reproduction steps.

spencer@: Can You also reproduce it in latest Canary fromhttps://www.google.com/chrome/browser/canary.html ?

Yep, same steps reproduce the problem in Chrome Canary too

shrike@ do you think this could be related to Issue 252895?

No Magic Mouse around but I tried to repro with an external trackpad and no luck. Maybe 10.13?

Unable to reproduce this issue on 62.0.3202.94 using Mac 10.13.1 and logitech mouse.

As ET-Hyd team doesn't have Magic mouse to check, could someone form MTV take a look into this issue.

Thanks!

> shrike@ do you think this could be related to Issue 252895?

I really am not sure.

If we can repro we can bisect. I have a magic mouse at home.

Assigning to shrike@ with the hope that you can test it.

I happen to be WFH today so am able to test with my magic mouse.

Here is a more exact set of steps (after pairing a magic mouse to a MacBook):

1. Open a new browser window
2. Go to apple.com
3. Go to android.com
4. Go to amazon.com
5. Single finger swipe to the right on the magic mouse to go back to android.com
6. Two-finger scroll of the android.com page on the built-in trackpad
7. Single finder swipe to the right on the magic mouse to go back to apple.com

I am able to reproduce this, going back as far as 51.0.2704.84, so it doesn't seem to be a regression.

[mac triage] This seems similar to  Issue 754649  - maybe erik can take a look.

I would love to try fixing this but I'm new to the code base and will need some pointers to get started. I have the repo and build setup locally, just not sure what part of the code I should be looking into.

spencer: The behavior you're observing is intentional:
https://cs.chromium.org/chromium/src/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.mm?type=cs&q=history_swiper.mm&sq=package:chromium&l=37

According to the comment [which I recall writing a long time ago], using [NSEvent trackSwipeEventWithOptions:] will brick subsequent NSTouch callbacks. If this is no longer the case on our lowest supported OS [macOS 10.9], then we can remove the code in question.

So I'd recommend trying to remove all logic that uses that flag, and see whether it works on your version of macOS. If it does work, we can try to narrow down when it started working, and either remove the code entirely, or at least add a OS version conditional.

Thanks for the pointers erikc...@chromium.org, I've dug in a bit and think I better understand the issue.

I believe `recognitionState_` is supposed to be initialized with `kPending` at the beginning of every gesture[1], but that is not done for magic mouse swipe gestures. After a vertical scroll, `recognitionState_ == kCancelled`, which causes `shouldConsumeWheelEvent` to return `NO` and the magic mouse gestures to be ignored. If you scroll horizontally a tiny mount the `recognitionState_` is reset to `kPending` and magic mouse gestures will begin working once again. Any vertical scrolling will once again cause the `recognitionState_` to be set to `kCanceled` and once again block magic mouse gestures.

This definitely smells like a bug, but I'm struggling to find how `recognitionState_` should be reinitialized when a magic mouse gesture is started.

[1]: https://cs.chromium.org/chromium/src/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.h?l=41-42

I started a cl that resets the `recognitionState_` when scrollWheel events are started, going to get some tests in before requesting review. If I'm doing something wrong please let me know...

https://chromium-review.googlesource.com/c/chromium/src/+/846203

kPending is currently set here: https://cs.chromium.org/chromium/src/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.mm?l=213

The problem, IIRC, is that after we call -[NSEvent trackSwipeEventWithOptions:...] we stop receiving touchesBeganWithEvent: callbacks from appkit. Given that we use touch events to perform normal history navigation, there's no way to work around this.

I'd recommend that you add a bunch of logging to RenderWidgetHostViewMac, e.g. at https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_mac.mm?type=cs&q=touchesBeganWithEvent&sq=package:chromium&l=2482.

"""
- (void)touchesBeganWithEvent:(NSEvent*)event {
  LOG(ERROR) << "touchesBeganWithEvent:";
  [responderDelegate_ touchesBeganWithEvent:event];
}
"""

, look at the sequence of callbacks sent by AppKit, and then use that information to decide what logic we should use to trigger history swiping.

`touchesBeganWithEvent` is not called for magic mouse swipe gestures though, which is the issue.

But it should be called for subsequent touchpad gestures?

Ah, perhaps I misinterpretted your reproduction steps.

"""
Steps to reproduce the problem:
1. Swipe to the right on the magic mouse to "go back"
2. Scroll with two fingers on the trackpad
3. Swipe to the right to go back no longer works
"""

I thought you meant that (3) no longer works with the trackpad. But I think you're saying that (3) no longer works with the magic mouse, because of the early return on https://cs.chromium.org/chromium/src/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.mm?l=528. 

I think, having only looked at the code, not tested it out, that the correct thing to do is to move the following 4 lines:
"""
  firstScrollUnconsumed_ = NO;
  rendererDisabledOverscroll_ = NO;
  waitingForFirstGestureScroll_ = NO;
  recognitionState_ = history_swiper::kPending;
"""

into beginGestureWithEvent:, but wrapped in a conditional:
(type == NSScrollWheel && phase == Began) || (type == BeginGesture)

Could you try that out and see if it fixes your problem [while still maintaining correct behavior for other, standard use cases?]

Awesome, will do