Is this only a issue in Gmail? 

What are you doing after step 3?

Can you attach a screencast of the issue? I do not really understand the problem :(

Thanks!

It's an issue in many web apps, not just Gmail, though it doesn't seem to occur on "simple" pages. A screenshot wouldn't be useful; I'll try to record a video of the problem. Let me try to explain the repro steps more clearly:

1. Open a long scrollable message in Gmail.
2. Start a normal 2-finger vertical scrolling gesture.
3. With your fingers held down, scroll up and down repeatedly.
4. While continuing to scroll vertically, rotate your hand so that your fingers rotate on the trackpad.
5. The arrow representing the "back" gesture appears on the left side of the page.
6. With your fingers still held down, try moving the arrow. You will notice that vertical scrolling moves the arrow horizontally, while horizontal scrolling has no effect, which is clearly wrong.

Note that step 5 does not always happen, so you may have to repeat steps 1-4 several times. I can get it to happen about once every 4 tries after some practice.

Thanks for the clearer steps. Now, I can reproduce with Chrome Version 30.0.1599.101 and Chrome Version 33.0.1704.0 canary on OSX 10.8.3.

Great! In case others have trouble reproducing, here's a video: http://www.youtube.com/watch?v=DbJoXOTxxEk

I hear erikchen@ is looking at going to look at Mac scrolling gestures. Assigning over.

Moving all non essential bugs to the next Milestone.

I see this behavior *without* rotating the two fingers 90 degrees. It is inconsistent in that I can't trigger it every time, but it happens I'd guess somewhere between 25-50% of the time. IOW, two fingers (side-by-side) vertical scroll gesture triggers the back gesture 25-50% of the time.

If you'd benefit from a video, I can try and capture one for you.

I can trigger this 100% of the time in a Gmail message frame (i.e., it seems to fire easily on scrollable divs, but not on native window scrollbars).

Steps to reproduce, in the middle of a long Gmail message: Two fingers maybe 1cm apart, in the bottom half of the trackpad, to start the scroll. Move them both upwards 5cm or more, then back down to their starting location. On the way back down, the back gesture will start to trigger (even though both fingers are moving vertically downwards).

I'm sorry to re-post on this, but wanted to share that I am now seeing this all the time, on all sites, and it's making Chrome unusable. I can no longer trust that a page I'm on won't instantly shift away in response to a scroll, which, as I'm sure you can imagine, can be disruptive on e-commerce sites, forum posts, basically anything interactive.

Any temporary workarounds would be appreciated, as would knowledge of when a fix for this creeps into a developer build as I'd shift to a beta to fix this.

(thanks to whomever is working on this!!!)

mehmet@, can you confirm a reproduction of this bug on 33stable, or any newer version? 
The behavior that I'm seeing is that as my fingers rotate into vertical swipes, sometimes the history swipe arrow appears, but the new vertical swipe to dismiss history swipe logic immediately kicks in and cancels the history swipe, which will never trigger again until I left my fingers.

erikchen: I see the same behavior like you described in your comment. (Tested in Chrome 33 and latest Canary on OSX 10.8.5)

---> A fast vertical up/down scrolling brings up the arrow animation for little a moment, but a history swipe is not triggered. A history swipe will trigger again, when I left my finger, put it again on the trackpad and do a horizontal swipe. (That's all fine except for that the arrow appears.)

May be a reason, why the arrow appears is, that the gmail page has no bounce effect area on the left/right side and additionally a fixed and a scrollable area on the page. I can reproduce it in my GMX mail account too. Same requirements: no bounce area on the left/right side, a fixed area and a scrollable area.

This issue has already been moved once and is lower than Priority 1,therefore removing mstone.

The last post was 9 months ago; have you forgotten about this bug? It still happens to me several times a day and is incredibly annoying—I'm considering disabling swipe navigation entirely despite how useful it is.

timothy: If you can provide more information, I can look into the problem.

What version of OSX/Chrome are you running?
Is the bug reproducible? What type of gesture do you have to make to accidentally trigger a history swipe? (If I can reproduce the problem on my machine, it would be a lot easier to fix).

Re-reading, it looks my experience may be slightly different from some other people’s. Let me know if I should open a new issue.

=== Setup ===
My setup is as follows (I haven’t done testing to see if any of these matter):
• natural scrolling enabled
• two-finger forward/back swipe gestures enabled (“Swipe between pages” in Trackpad > More Gestures)
• using internal trackpad of my Early 2009 MBP
• OS 10.10.1 with both Google Chrome 39.0.2171.95 and Chromium 41.0.2266.0 (Developer Build)

=== Reproduction ===
I can’t make it happen; it always seems to strike when I least expect it! But when it does:
• I simply scroll with two fingers normally. My fingers are side-by-side horizontally, moving vertically upward (to scroll downward).
• If I don’t notice and let go, Chrome treats it as a “back” gesture.
• If I do notice, while keeping my fingers touching, I can move them up and down, and the back arrow will slide in and out just like it does with the swipe forward/back gesture.
• If I move my fingers back (before letting go), the gesture is cancelled (just like the actual back gesture is treated).

This bug also affects a friend of mine. It’s possible there’s a third-party variable that’s causing it; I will keep testing on my own and let you know if I find anything.

Thanks for looking into this!

Have you ever noticed the opposite effect? (Moving your fingers vertically downward causes Chrome to treat it as a "forward" gesture)

The next time this bug happens to you, can you run a quick test?

- Sliding up and down causing the arrow to appear/disappear. Before removing your fingers, what does sliding left/right do? 
  - Does it cause the arrow to appear/disappear faster?
  - Does it cause the arrow to disappear entirely?

Left/right movement has no effect on anything.

It's never happened that upwards scrolling has triggered a forwards gesture, but I don't know if it *wouldn't* happen. I think it's somehow connected with when a page is loading, specifically, so I'd never be scrolling up at the time. Not sure about that, though.

Additionally, I've discovered that it works with my Magic Mouse too! That only uses one finger to scroll (also naturally), but the navigation gestures are also done with one finger, so it doesn't really narrow it down much. However, we do know that it isn't limited to trackpads or two-finger scrolling.

Breakthrough:
This bug is frequently reproducible by swiping forward or backward and immediately scrolling while the page is loading. Upwards scrolling does trigger a forwards gesture in the same manner. I think there's still another variable; there might need to be at least two pages in the forward/backward queue.

I thought it happened at other times, too, but I might have fabricated those memories.

Thanks for the info! I will take a look this week. :)

I was able to reproduce the problem, with a little cheating on my end.

Modify chrome_render_widget_host_view_mac_history_swiper.mm so that forceMagicMouse = YES. Compile and run. Vertical swipes during page load now trigger history swipes.

The cause: Once the forceMagicMouse switch has been set, a completely different code path is used. This alternate code path relies on the API [NSEvent trackSwipeEventWithOptions:dampenAmountThresholdMin:max:usingHandler:]. Notice that the API doesn't actually take a direction! This API locks the gesture into one of the axes, which is sometimes the vertical axis.

This code path is only supposed to trigger if the user is using a Magic Mouse, but I noticed that if I left Chrome open on my MacbookAir long enough, it would eventually switch into this code path.

Issue 439440 has been merged into this issue.

There are several problems.

1. There's an AppKit bug. As soon as [NSEvent trackSwipeEvent:...] API gets called, the NSView stops receiving touchesBeganWithEvent: callbacks.
2. I knew about the bug in (1), but I forgot about it when writing some code a couple of months ago.
3. The code path was magic mouse history swiping is being triggered even when no magic mouse is ever used.

I'm going to file a radar against Apple for (1). I'm going to write up a short fix for (2). 

(3) seems possible since AppKit does not guarantee the order of callbacks regarding the APIs beginGestureWithEvent: touchesBeganWithEvent: and scrollWheel:. I'm not sure there are any immediate changes I want to make on that fornt.

Attached a sample app demonstrating the AppKit bug.

SampleSwipeApp.zip 36.6 KB Download

I submitted radar 19461352.

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

commit de515231c665422838bf93883a126b154d2e65ff
Author: erikchen <erikchen@chromium.org>
Date: Thu Jan 15 23:20:58 2015

Fix Magic Mouse history swiping bug.

Magic Mouse gestures don't cause -touches*WithEvent: events to be sent down the
responder chain. As such, all state related to Magic Mouse gestures needs to be
reset during -beginGestureWithEvent:.

BUG= 317161 

Review URL: https://codereview.chromium.org/821173003

Cr-Commit-Position: refs/heads/master@{#311762}

[modify] http://crrev.com/de515231c665422838bf93883a126b154d2e65ff/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.h
[modify] http://crrev.com/de515231c665422838bf93883a126b154d2e65ff/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.mm
[modify] http://crrev.com/de515231c665422838bf93883a126b154d2e65ff/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper_unit_test.mm

Which version is this fixed in? Seems like the issue is still there in 41. 

This is fixed in Chrome 42 (beta)

Let's set a label to make it clear.

Issue 467887 has been merged into this issue.

Issue 471383 has been merged into this issue.

Has this issue regressed in a recent Chrome version?  I keep getting this old bad vertical scroll/back behavior as of today.

This is not fixed at all!
Problem is back & very annoying.
Filling in forms & scrolling to bottom of page is dangerous & frustrating...

To clarify bug:
I'm on ElCapitan

Tried on the same long page:
. scroll past end of page, 
. with a single finger downwards at the end of page
. on Magic Mouse
. on a local URL. When trying to find a public site with the same behavior, I didn't find one quickly... 

Result:
. Chrome 45: goes back, while showing the back-gesture icon at left of screen
. Safari 9: nothing happens
. Firefox 40: nothing happens

Since 46 version issue appears again.

I'm also experiencing this issue.