New issue
Advanced search Search tips

Issue 856525 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 30
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Event.layerY differs from Event.pageY

Reported by fun07.ma...@gmail.com, Jun 26 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Example URL:
https://marci4.github.io/testpage/canvaslayerpage.html

Steps to reproduce the problem:
1. Open url and console
2. Scroll to the end of the page
3. Click on the canvas

What is the expected behavior?
Both layerY and pageY are equal.

What went wrong?
The event position in layerY differs from pageY.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? Yes 60.0.3112.78

Does this work in other browsers? Yes

Chrome version: 67.0.3396.99  Channel: stable
OS Version: 10.0
Flash Version: 

Could also have worked later but only hat a Chrome 60 on my pc.
 
Components: Blink>Input
Labels: Needs-Bisect Needs-Triage-M67
Cc: susan.boorgula@chromium.org
Labels: -OS-Windows -Pri-2 -Type-Compat -Needs-Bisect hasbisect-per-revision Triaged-ET M-69 RegressedIn-64 Target-67 FoundIn-67 Target-68 Target-69 FoundIn-68 FoundIn-69 OS-Mac Pri-1 Type-Bug-Regression
Owner: eirage@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on Mac OS 10.13.3 on the latest Canary 69.0.3473.0 and Stable 67.0.3396.99 as per the original comment.
Issue is not observed on Windows 10 and Ubuntu 14.04.
Attached is the screen cast of the Windows behavior.

Bisect Information:
===================
Good Build: 64.0.3263.0
Bad Build : 64.0.3264.0

By running the per-revision bisect script, below is the Changelog URL.

https://chromium.googlesource.com/chromium/src/+log/b99d3c235b805c762d4f8227c845b7f8ab105343..9d5de00296c359ea4b91c71fffd41cc2ad28dd41

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/753511

eirage@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Thanks
856525-windows.mp4
1.7 MB View Download
Hello,

thank you for reproducing the issue!

As it seems in the video, you have not scrolled to the end of the page.
Scrolling to the end shows the difference better!

Sorry, if I was not exact enough with my steps to reproduce.

Best regards,
Marcel Prestel

Comment 5 by eirage@chromium.org, Jun 27 2018

Cc: bokan@chromium.org nzolghadr@chromium.org
I don't think it's a regression.
Our calculation of layer position seems wrong when ancestor layer is absolute.
 
Any reason you want to use layerX/Y attributes? These attributes are not specced.

However, alternative ones screenX/Y, clientX/Y, pageX/Y (, and offsetX/Y which itself might have some compat issues) should cover all use cases pretty much.
Attached you can find a video showing why I think this is a regression.


Unfortunately, my colleague is on holiday, I don't know why he decided to use this attribute. Since our product just gets updated 2 times a year, we have no good way to fix such a behaviour for most of our customers.
Aufnahme #1.mp4
400 KB View Download
Labels: Needs-Bisect
The video in #3 appears to show correct behavior because there is no scroll. Could we get a new bisect please - scrolling to the bottom of the page and comparing the values.

Cc: phanindra.mandapaka@chromium.org
Labels: -Needs-Bisect -RegressedIn-64 RegressedIn-66 OS-Linux OS-Windows
Able to reproduce issue on reported chrome version 67.0.3396.99 & on latest chrome 69.0.3481.0 using Windows 10,Ubuntu 14.04 and Mac 10.13.5. Hence providing bisect information below.

Bisect Info:
================
Good build: 66.0.3344.0
Bad build: 66.0.3345.0

You are probably looking for a change made after 535635 (known good), but no later than 535637 (first known bad).

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/e04a14f4769d6b33b32686ccc3414e917a625ae7..a5676deb1e679035678bc1ed997518cd226378b9

suspect: https://chromium.googlesource.com/chromium/src/+/96f85b68747a679ea1ac4cd05d6743ae5f7142b7

Reviewed-on: https://chromium-review.googlesource.com/857902

@skobes: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!
Owner: skobes@chromium.org
Project Member

Comment 11 by bugdroid1@chromium.org, Aug 29

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

commit 237cebe7d7e2265e07c78fc73d22a02b1a80ff71
Author: Steve Kobes <skobes@chromium.org>
Date: Wed Aug 29 18:24:15 2018

Fix coordinate conversion for layerX / layerY in abs-pos block.

PaintLayer::location_ is relative to the containing block, not the
parent layer.  For a MouseEvent on a position: absolute element, we were
adding the parent layer's location to a value that already included it,
which doesn't make sense.

The behavior of layerX and layerY remains quirky and not standardized.
There is an open issue at https://github.com/w3c/uievents/issues/135.
It's unclear if the FIXME about ConvertToLayerCoords is still correct.

Bug:  856525 
Change-Id: Iba5bb7b2c955b4bd526597628cd789ff0eb42e90
Reviewed-on: https://chromium-review.googlesource.com/1195648
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587202}
[add] https://crrev.com/237cebe7d7e2265e07c78fc73d22a02b1a80ff71/third_party/WebKit/LayoutTests/fast/events/mouse-layerXY-scrolled.html
[modify] https://crrev.com/237cebe7d7e2265e07c78fc73d22a02b1a80ff71/third_party/blink/renderer/core/events/mouse_event.cc

Status: Fixed (was: Assigned)
Fixed in canary (70.0.3537.0).

Sign in to add a comment