New issue
Advanced search Search tips

Issue 758429 link

Starred by 2 users
Status: Started
Owner:
thomasanderson@chromium.org
Cc:
kkaluri@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

screenX value of drag event incorrect on secondary monitor

Reported by kartride...@gmail.com, Aug 24 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3193.0 Safari/537.36

Steps to reproduce the problem:
1. get two monitors, set the right one as the main monitor
2. open chrome in the left monitor with a pic, https://chromiumbugs.appspot.com/static/images/logo.png
3. open devtools console and run 
monitorEvents(window, 'drag');
4. drag the pic

What is the expected behavior?
sceenX of the drag event should be negative values since it's left to the main screen.

What went wrong?
the first drag event contains the right screenX value but in the following drag events screenX becomes positive values (equals clientX)

Did this work before? Yes not sure, at least 55?

Does this work in other browsers? N/A

Chrome version: 62.0.3193.0  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 27.0 r0
crsr.PNG
33.1 KB View Download

Comment 1 by kkaluri@chromium.org, Sep 8 2017

Cc: kkaluri@chromium.org
Components: UI>Shell>MultipleMonitor
Labels: Needs-Triage-M62 Needs-Feedback
Tested this issue on Windows 10 with chrome stable #61.0.3163.79, #54.0.2840.0, #50.0.2661.0 and observed the same behavior in all versions.

Steps Followed:
1. launched the chrome in 2nd monitor.
2. navigated to test url and entered the code in "monitorEvents(window, 'drag');" in the console.
3. dragged the icon

Observed all positive values for screenX. Attaching the screen-cast for reference.

kartrider.wu@ could you please look into it and let us know any steps i have missed while reproducing the scenario.

Thank You...
758429.mp4
5.2 MB View Download

Comment 2 by kartride...@gmail.com, Sep 9 2017 

hi kkaluri, would you please make the right monitor as main display ? like this:
1|2(main)
and test on display 1.
thank you
Project Member

Comment 3 by sheriffbot@chromium.org, Sep 9 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 4 by kkaluri@chromium.org, Oct 12 2017

Labels: -Pri-2 hasbisect-per-revision OS-Android Pri-1
Owner: thomasanderson@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Windows 10 with chrome Stable #61.0.3163.100 , Canary #63.0.3236.0 as per comment #2.
Issue broken in M56

Bisect Info:
===========
Good build :  56.0.2884.0,  Revision Range - 424021
Bad build  :  56.0.2885.0,  Revision Range - 424072

After executing the per-revision bisect script, i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/a420fe39c98570d80347675134d3738af20c63b7..5dfbc0a96c848ec1e232d543921330cc7aaa15f4

The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/5dfbc0a96c848ec1e232d543921330cc7aaa15f4

Note: Not able to repro on Ubuntu 14.04 & Mac 10.12.6

thomasanderson@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Comment 5 by ajha@chromium.org, Oct 12 2017

Labels: -OS-Android

Comment 6 by thomasanderson@chromium.org, Oct 13 2017

Status: Started (was: Assigned)

Comment 7 by thomasanderson@chromium.org, Oct 16 2017 

kkaluri: we have a proposed CL here https://chromium-review.googlesource.com/c/chromium/src/+/717557

But I do not have a Windows machine with 2 monitors to test the CL.  Could you verify if the CL fixes the issue?
►

Sign in to add a comment