Mac: Support Sierra's broken MouseWheel events.

content/browser/renderer_host/input/web_input_event_builders_mac.mm

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 /*
  * Copyright (C) 2004, 2006, 2007 Apple Inc. All rights reserved.
  * Copyright (C) 2006-2009 Google Inc.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ skipping 533 matching lines @@
   DCHECK(cg_event);
 
   // Wheel ticks are supposed to be raw, unaccelerated values, one per physical
   // mouse wheel notch. The delta event is perfect for this (being a good
   // "specific edge case" as mentioned above). Trackpads, unfortunately, do
   // event chunking, and sending mousewheel events with 0 ticks causes some
   // websites to malfunction. Therefore, for all continuous input devices we use
   // the point delta data instead, since we cannot distinguish trackpad data
   // from data from any other continuous device.
 
+  int64_t pointDeltaX = CGEventGetIntegerValueField(
+        cg_event, kCGScrollWheelEventPointDeltaAxis2);
+  int64_t pointDeltaY = CGEventGetIntegerValueField(
+        cg_event, kCGScrollWheelEventPointDeltaAxis1);
+
   if (CGEventGetIntegerValueField(cg_event, kCGScrollWheelEventIsContinuous)) {
-    result.deltaX = CGEventGetIntegerValueField(
-        cg_event, kCGScrollWheelEventPointDeltaAxis2);
-    result.deltaY = CGEventGetIntegerValueField(
-        cg_event, kCGScrollWheelEventPointDeltaAxis1);
-    result.wheelTicksX = result.deltaX / ui::kScrollbarPixelsPerCocoaTick;
-    result.wheelTicksY = result.deltaY / ui::kScrollbarPixelsPerCocoaTick;
+    result.deltaX = pointDeltaX;
+    result.deltaY = pointDeltaY;
+    result.wheelTicksX = pointDeltaX / ui::kScrollbarPixelsPerCocoaTick;
+    result.wheelTicksY = pointDeltaY / ui::kScrollbarPixelsPerCocoaTick;
     result.hasPreciseScrollingDeltas = true;
   } else {
     result.deltaX = [event deltaX] * ui::kScrollbarPixelsPerCocoaTick;
     result.deltaY = [event deltaY] * ui::kScrollbarPixelsPerCocoaTick;
+
+    // A rounding bug on Sierra means that single-tick wheel scrolls may be
+    // truncated to zero. Prefer kCGScrollWheelEventPointDeltaAxisXY in those
+    // cases. First assume the CGEventSource has the default value of 10, rather

[Avi (use Gerrit), 2016/10/31 13:32:59]

"First" assume? I'm not sure what you mean by that comment.

I'm not sure how CGEventSourceGetPixelsPerLine() works. Does it tend to stay the
same for multiple calls? Why not cache it?

[tapted, 2016/11/01 02:29:46]

Ah, there were more steps earlier :). Should be more clear now.
Yeah - the documentation suggests that it will be the same unless something
changes it with CGEventSourceSetPixelsPerLine . But the documentation is unclear
about how this may be shared between processes (i.e. Chrome certainly doesn't
call CGEventSourceSetPixelsPerLine).

As for caching it.. One issue is that
CGEventSourceGetPixelsPerLine(CGEventSource) requires a CGEventSource, but
CGEventGetSource(CGEvent) is deprecated -

https://developer.apple.com/reference/coregraphics/1658572-quartz_event_servi...

Instead there is only "CGEventCreateSourceFromEvent" which has a less clear
lifetime, and the documentation says it may also return null (maybe if some
other process is injecting events into Chrome?)

CGEventSourceSetPixelsPerLine says

/* Set the scale of pixels per line in a scrolling event source.

   This function sets the scale of pixels per line in the specified event
   source. For example, if you pass the value 12 as the `pixelsPerLine'
   parameter, the scale of pixels per line in the event source would be
   changed to 12. Every scrolling event can be interpreted to be scrolling
   by pixel or by line. By default, the scale is about ten pixels per
   line. */


So just using the default of 10 seems to give predictable results.

And I'm actually not sure what AppKit does behind the scenes (they're both
accelerated, but "differently") -- the actual relationship can be as low as 5x
instead of 10x when momentum ramps up, and the same value of
kCGScrollWheelEventPointDeltaAxisX (e.g. -11) doesn't always give the same value
of `[event deltaX]` (e.g. -11 could be -1.01988, or -1.086). So using
CGEventSourceGetPixelsPerLine seems to give more credibility to the calculation
when really it's a big 'ol guesstimate. There's not even consistency with the
cutoff. E.g. Sometimes -4 will have deltaX of zero, sometimes it will be
-0.358704

I've updated the comment about this.

+    // than querying CGEventSourceGetPixelsPerLine() each time.
+    const float kPixelsPerLine = 10.0;
+    if (result.deltaX == 0 && pointDeltaX != 0)
+      result.deltaX = pointDeltaX * kPixelsPerLine;
+    if (result.deltaY == 0 && pointDeltaY != 0)
+      result.deltaY = pointDeltaY * kPixelsPerLine;
+
     result.wheelTicksY =
         CGEventGetIntegerValueField(cg_event, kCGScrollWheelEventDeltaAxis1);
     result.wheelTicksX =
         CGEventGetIntegerValueField(cg_event, kCGScrollWheelEventDeltaAxis2);
   }
 
   result.timeStampSeconds = [event timestamp];
 
   result.phase = PhaseForEvent(event);
   result.momentumPhase = MomentumPhaseForEvent(event);
@@ skipping 40 matching lines @@
       break;
     default:
       NOTIMPLEMENTED();
       result.type = blink::WebInputEvent::Undefined;
   }
 
   return result;
 }
 
 }  // namespace content