Edge seems working fine. However, PointerEvent.clientX/Y coordinates in Edge seems to be real numbers, not integers.

bokan@, do you know where coordinate transformation for scrolling takes place before sending the event off to an iframe?

Nope. For mouse and scroll events we pass the event to progressively more nested iframes like here: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/input/EventHandler.cpp&sq=package:chromium&type=cs&l=4067&rcl=1461251912

But I'm actually not sure where the values get set for client coordinates.

Could this be caused by the issue I brought up in Navid's code review and we filed a TODO:  issue 608394 

Yes, that bug seems to be talking about the same problem.

Have a few questions, to understand why we didn't hit this bug before PointerEvents:
- For TouchEvents, is "root frame" equivalent to "touchstart frame"?
- Mouse events fired for touches would need the same coodinates as PEs. Does this adjustment make sense?
  https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/input/EventHandler.cpp&rcl=1462288634&l=2177

I think this is the right solution: MEs from TouchEvents don't even care about the adjusted positions, just using position() & globalPosition() should be fine (as done in EventHandler::handleGestureTap).

I think the other bug can be closed: TouchEvents have no problem in iframes (otherwise, e.g., all Maps frame would feel broken).

Navid has agreed to focus on this bug instead: just defer the computation of adjusted points until right before firing TouchEvents, so that PointerEvents see the "raw" coordinates in PlatformEvent.

We will close the other bug ( crbug.com/608394 ) after we have a test, part of this bug's fix or not.

> - For TouchEvents, is "root frame" equivalent to "touchstart frame"?

Not sure as I don't know this code well but if the name is good, "touchstart frame" says to me that it should be the frame where the touch started. "root frame" should always be relative to the top level frame (i.e. window).

> Mouse events fired for touches would need the same coodinates as PEs. Does this adjustment make sense?

It makes sense assuming PlatformGestureEvent::position is in root frame coordinates. The only place this adjustedPosition is used is to do a hit test which is generally done on "content coordinates". But, taking a quick look at [1] it seems PGE::position is in the hit frame's coordinate space, not the root frame's.

Side note: "adjusted position" doesn't have any meaning. Lets settle on a more precise naming convention:

Content/Page Coordinates: Relative to the document origin (i.e. affected by scroll offset)
Frame/Client Coordinates: Relative to the frame origin (i.e. unaffected by scroll offset)
Root Frame Coordinates: Same as frame coordinates but specifically denotes the root frame
Viewport Coordinates: Relative to the Blink widget's origin. (i.e. unaffected by scroll or pinch-zoom)

[1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/web/WebInputEventConversion.cpp&rcl=1462288634&l=317

> I think the other bug can be closed: TouchEvents have no problem in iframes (otherwise, e.g., all Maps frame would feel broken).

If we do, I'd like to see where my analysis went wrong. If the code is correct then there's a wrong variable name somewhere and that needs to be fixed. I'm also not convinced that Maps would show this problem since Maps appears to draw into a canvas, meaning there's no scrolling in the frame (the canvas keeps it's own panning offset) so frame == content coordinates in that case.

I guess I don't know much about canvas to support my claim here. What about non-canvas iframes?

In any case, I agree that we shouldn't close the other bug. Let's discuss the touch specific issues there.

My original post that the offset in clientX/Y depends on scroll position is for mouse, and this doesn't repro for touch. Sorry for the mixup.

I see one possible crack in the code: are setting UIEvent.view to m_frame->document()->domWindow() for PEs, but to targetNode->document().domWindow() for MEs. Still not sure if this might be affecting the coordinates during/after dispatch.

Here is the real bug: PointerEventManager::dispatchMouseEvent populates clientX/Y coordinates ultimately through MouseRelatedEvent::MouseRelatedEvent(...) constructor:
  https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/events/MouseRelatedEvent.cpp&rcl=1462447110&l=54
which does some sort adjustment before setting m_clientLocation.

We chose to use a PointerEventInit based version of PointerEvent::create(...) to avoid passing a long list of parameters, and inadvertently bypassed the MouseRelatedEvent::MouseRelatedEvent(...) call from MouseEvent::create(...).

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

commit 85ece81cc3561eb24ecc96f25d7ae9ecd40c219f
Author: nzolghadr <nzolghadr@chromium.org>
Date: Thu May 12 14:47:53 2016

Fix mouse pointer event clientX/Y

Before this change the clientX/Y was set from
root frame coordinates. This CL transform such
coordinates to frame coordinates for setting
clientX/Y.

BUG= 605676 

Review-Url: https://codereview.chromium.org/1960233002
Cr-Commit-Position: refs/heads/master@{#393247}

[modify] https://crrev.com/85ece81cc3561eb24ecc96f25d7ae9ecd40c219f/third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/pointer-event-properties-in-iframe-expected.txt
[modify] https://crrev.com/85ece81cc3561eb24ecc96f25d7ae9ecd40c219f/third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/pointer-event-properties-in-iframe.html
[modify] https://crrev.com/85ece81cc3561eb24ecc96f25d7ae9ecd40c219f/third_party/WebKit/Source/core/events/PointerEventFactory.cpp
[modify] https://crrev.com/85ece81cc3561eb24ecc96f25d7ae9ecd40c219f/third_party/WebKit/Source/core/events/PointerEventFactory.h
[modify] https://crrev.com/85ece81cc3561eb24ecc96f25d7ae9ecd40c219f/third_party/WebKit/Source/core/input/EventHandler.cpp
[modify] https://crrev.com/85ece81cc3561eb24ecc96f25d7ae9ecd40c219f/third_party/WebKit/Source/core/input/PointerEventManager.cpp
[modify] https://crrev.com/85ece81cc3561eb24ecc96f25d7ae9ecd40c219f/third_party/WebKit/Source/core/input/PointerEventManager.h