Redirecting to Elliot.

Interesting thing noticed: some ui::Events (but only some of them!) have the same location for their location() and root_location(). I first thought this was some issue with events being sent back from the renderer, but it appears that this is in the initial ui::Event sent in the first place.

I think there's a deeper problem with event locations here.

Traced this up into the ui::EventDispatcher code. The EventDispatcher code appears to be the last entity that these events have proper root locations set on; downwards in the ui::EventDispatcherDelegate::DispatchEvent() phase, they have the root location set to the normal location.

I don't know why this is changing the root location away from the correct values...and only for some of the events. The majority of events aren't changed.

Redirecting to sadrul@ since I'm lost deep in the ui::EventProcessor code. The
actual mouse down/mouse up events coming from the window server are correct,
and end up incorrect way before the DragDropClient sees them.

ui::Events which enter EventProcessor::OnEventFromSource() have their
location() and root_location() set correctly in local and screen bounds
respectively. During normal dispatch, OnEventProcessingStarted() will throw
away the root location and set it to the window location. Then
GetRootForEvent() will recalculate the root window location and set both
location() and root_location() to it. Then a call to FindTargetForEvent() will
further mutate the event back to how it originally was.

This is broken in the case of mouse up and down events in mus, which don't get
their normal location() set back to how it was at the start of the
function. GetRootForEvent() goes into the FindTargetInRootWindow() case and
then performs no conversion because the target is the event_target.

I don't know what this should do instead.

705690 is another manifestation of this. The touch events there have the same offset problem going into the TouchHID code, but have the right global coordinates coming into it.

706200 also has a minor manifestation of this, though this time with mouse events instead of touch events.

Right now, on tip of tree with --mus, if you enable screen magnification (don't need to zoom in or out, just need to have it enabled), when you open the system tray bubble and hover over it, the software cursor jumps to the left side of the screen, as if it were interpreting the system tray window local bounds as display bounds.

It is. This is another case where at the top of EventProcessor::OnEventFromSource(), the location and root_location differ and are set correctly, and by the time dispatch occurs root_location() has been set to location().

(The event sets its wrong root_location to Env::last_mouse_location() and that's how the software cursor position gets set erroneously.)

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

commit 8b679cacf3465630201734047fd8734d711a5624
Author: Elliot Glaysher <erg@chromium.org>
Date: Fri Aug 18 17:14:16 2017

events: Fix updating an Event's root location.

This patch was written originally by sadrul@; it's been modified just to
make unit tests pass.

Bug:  735710 ,  705690 ,  706200 ,  755780 
Change-Id: I676eba681899fe3ddd8b967382738c68449881eb
Reviewed-on: https://chromium-review.googlesource.com/619567
Commit-Queue: Elliot Glaysher <erg@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495593}
[modify] https://crrev.com/8b679cacf3465630201734047fd8734d711a5624/ui/aura/mus/window_tree_client_unittest.cc
[modify] https://crrev.com/8b679cacf3465630201734047fd8734d711a5624/ui/events/event.cc
[modify] https://crrev.com/8b679cacf3465630201734047fd8734d711a5624/ui/events/event_unittest.cc