Mac: Offset test scroll events when attaching them to an NSWindow.

ui/events/test/cocoa_test_event_utils.mm

Index: ui/events/test/cocoa_test_event_utils.mm
diff --git a/ui/events/test/cocoa_test_event_utils.mm b/ui/events/test/cocoa_test_event_utils.mm
index 8bf1837edb4506a4e8ccec873494be411f5a5382..9bd42df4ef83bdd4800800ca2f25ab94715dfb79 100644
--- a/ui/events/test/cocoa_test_event_utils.mm
+++ b/ui/events/test/cocoa_test_event_utils.mm
@@ -25,6 +25,21 @@ CGPoint ScreenPointFromWindow(NSPoint window_point, NSWindow* window) {
 }
 
 NSEvent* AttachWindowToCGEvent(CGEventRef event, NSWindow* window) {
+  // -[NSEvent locationInWindow] changes from screen coordinates to window
+  // coordinates when a window is attached to the mouse event. -[NSEvent
+  // eventWithCGEvent:] handles the Quartz -> AppKit coordinate flipping, but
+  // not the offset. Unfortunately -eventWithCGEvent: uses the *screen* height
+  // to flip, not the window height (it doesn't know about the window yet). So
+  // to get the correct -[NSEvent locationInWindow], anticipate the bogus screen
+  // flip that eventWithCGEvent: will do. This is yuck, but NSEvent does not
+  // provide a way to generate test scrolling events any other way. Fortunately,
+  // once you do all the algebra, all we need to do here is offset by the window
+  // origin, but in different directions for x/y.

[Avi (use Gerrit), 2016/11/08 16:20:47]

o_O

Is there a bug filed? This is surprising. (Though not really.)

[tapted, 2016/11/08 23:05:52]

No bug.. It's annoying, but I think it's reasonable for things to be this way.
It would be "nice" if NSEvent provided ways to make test events specifically for
trackpad scrolling, but it's often device-specific, and Apple's opinion is
probably that only NSScrollView should ever care about them and NSScrollView
will do the Right Thing for you.

Instead, all they give is +[NSEvent eventWithCGEvent:] - there's no way to pass
in an NSWindow with this initializer, so it's reasonable that NSEvent caters for
part of the coordinate conversion, but not all of it.

It would also be nice if NSEvent had some mutators - its API is immutable, but
AppKit has access to the internals and tinkers with things during event
dispatch.

And while I'm at it, it would be nice if Mac didn't use different coordinate
systems for CG events and NS events :p

I don't see NSEvent becoming mutable any time soon, so I think all I can really
do  is file a rdar asking for better methods to create test NSEvents for
scrolling.

[tapted, 2016/11/08 23:54:20]

Filed http://crbug.com/663553 that collects my current research around
cocoa_test_event_utils:: and the things I dream of doing to it one day.

+  CGPoint location = CGEventGetLocation(event);
+  location.y += NSMinY([window frame]);
+  location.x -= NSMinX([window frame]);
+  CGEventSetLocation(event, location);
+
   // These CGEventFields were made public in the 10.7 SDK, but don't help to
   // populate the -[NSEvent window] pointer when creating an event with
   // +[NSEvent eventWithCGEvent:]. Set that separately, using reflection.
@@ -207,6 +222,8 @@ NSEvent* TestScrollEvent(NSPoint window_point,
   DCHECK_EQ(has_precise_deltas, [event hasPreciseScrollingDeltas]);
   DCHECK_EQ(event_phase, [event phase]);
   DCHECK_EQ(momentum_phase, [event momentumPhase]);
+  DCHECK_EQ(window_point.x, [event locationInWindow].x);
+  DCHECK_EQ(window_point.y, [event locationInWindow].y);
   return event;
 }