Fix page navigation being incorrectly fired on Mac OSX.

chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.h

Index: chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.h
diff --git a/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.h b/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.h
index 47fe073dff18a04bfcb37d393927d68358ae04a4..538fbd7f00196851b1e51110ef7c2f4d1952fbf4 100644
--- a/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.h
+++ b/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.h
@@ -8,6 +8,7 @@
 #import <Cocoa/Cocoa.h>
 
 namespace blink {
+class WebGestureEvent;
 class WebMouseWheelEvent;
 }
 
@@ -155,7 +156,8 @@ enum RecognitionState {
 
   // Whether the event with phase NSEventPhaseBegan was not consumed by the
   // renderer. This variables defaults to NO for new gestures.

[erikchen, 2016/04/01 03:44:56]

This comment applies to the previous ivar, which I understood. I don't
understand the new ivars, nor why you need two rather than just one. 

Is this the right doc?
https://docs.google.com/document/d/19sFYkMUwJcgQTxM1GakrCryHOZpNeL2c41jxWB7rS...

My understanding:
1. The OS sends NSEventPhaseBegin/Moved/Ended events to the browser, which are
forwarded to blink.
2. Blink converts these to GestureScrollBegin/Update/End events.
3. Depending on whether the relevant layer has passive, blocking, or no
listener, a different message is sent to the main thread. [which thread is this
done on? impl thread?]
4. The main thread then forwards the results to the browser.

If this is accurate, why does the browser need to know about
GesturescrollEvents? That seems like an implementation detail of Blink. The
embedder passes in a wheel event, and just needs to know whether Blink consumed
it.

[erikchen, 2016/04/01 16:18:58]

Please add your explanation here, as well as updated comments for these two
ivars.

Based on your explanation, would an ivar named gestureScrollUnconsumed_ make
more sense?

[dtapuska, 2016/04/01 17:22:25]

The logic is about the first gesture scroll after the phase began is unconsumed.
Not that the gesture scroll was unconsumed.

ie; in the example GSB, GSU(A), GSU(B), GSU(C), GSE

GSU(A), GSU(B) could be consumed, but GSU(C) won't trigger the arrow.

But in example: GSB, GSU(X), GSU(Y), GSE

GSU(X) goes unconsumed then it will trigger the arrow.

[erikchen, 2016/04/01 17:57:34]

I'm sorry, but I don't understand your explanations. You're using the terms
"won't trigger the arrow" and "trigger the arrow", but I don't know if you're
describing the previous behavior, or the behavior that you are trying to induce.

Can you update the comments for this ivars to describe what they mean?

[dtapuska, 2016/04/01 19:00:25]

Done.

-  BOOL beganEventUnconsumed_;
+  BOOL firstScrollUnconsumed_;
+  BOOL nextScrollUpdatesUnconsumed_;
   history_swiper::RecognitionState recognitionState_;
 
   id<HistorySwiperDelegate> delegate_;
@@ -171,6 +173,8 @@ enum RecognitionState {
 - (BOOL)handleEvent:(NSEvent*)event;
 - (void)rendererHandledWheelEvent:(const blink::WebMouseWheelEvent&)event
                          consumed:(BOOL)consumed;
+- (void)rendererHandledGestureScrollEvent:(const blink::WebGestureEvent&)event
+                                 consumed:(BOOL)consumed;
 
 // The event passed in is a gesture event, and has touch data associated with
 // the trackpad.