Issue metadata
Sign in to add a comment
|
drop event has wrong position on surface book
Reported by
rin...@gmail.com,
Sep 6 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36 Example URL: http://jsfiddle.net/p6jcvkro/2/ Steps to reproduce the problem: 1. I'm not able to reproduce it on other device yet, it only happens on surface book 2. open http://jsfiddle.net/p6jcvkro/2/ 3. drag the red box and drop to yellow box What is the expected behavior? the last position of dragover event should be same position as drop position What went wrong? position of drop event is very different from the last dragover event Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 53.0.2785.89 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0
,
Sep 7 2016
rinick@ Thanks for the issue. Able to reproduce the issue on windows 7 using chrome version 53.0.2785.89.This is working fine on canary 55.0.2853.0. Also this issue got fixed in latest builds.Next stable build will be available in few days. Could you please check the issue on next stable build and update the thread if the issue still persists. Thanks,
,
Sep 7 2016
,
Sep 7 2016
,
Sep 7 2016
,
Sep 7 2016
govind@ is this a release blocker?
,
Sep 7 2016
+ pbommana@, could you please check this on latest M53 stable build.
,
Sep 7 2016
Doesn't repro on my desktop and I don't have a surfacebook to test with. I bet it has something to do with touch events. I don't think this is a release blocker. Adding a couple people who have surfacebooks in case they want to pick this up.
,
Sep 7 2016
Thank you bsep@ for confirmation. I will move forward with the release.
,
Sep 15 2016
,
Sep 16 2016
This occurs when the device has the zoom level > 100%. The surfacebook will most likely have a zoom level 200% if you reduce it down to 100% it will work again. This is a regression and didn't occur on versions < 53
,
Sep 16 2016
Note I am not talking about the browser zoom I am talking about the monitor. (Display preferences)
,
Sep 19 2016
kavvaru@ the issue still exists in latest version, I just tested with Version 55.0.2865.0 canary (64-bit),
,
Sep 22 2016
Ok I got my hands on a surface book and confirmed that it reproduces there, so I'll work on this.
,
Sep 27 2016
Automated comment is missing but I landed a fix for this here: https://codereview.chromium.org/2370523002
,
Sep 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9d8c853ad24d06a02013df4335a230be723c3065 commit 9d8c853ad24d06a02013df4335a230be723c3065 Author: bsep <bsep@chromium.org> Date: Tue Sep 27 18:19:23 2016 Fix drop event location being incorrect at hidpi. Only a problem with use-zoom-for-dsf on, but that is now default on Windows and ChromeOS. BUG= 644421 Review-Url: https://codereview.chromium.org/2370523002 Cr-Commit-Position: refs/heads/master@{#421271} [modify] https://crrev.com/9d8c853ad24d06a02013df4335a230be723c3065/content/renderer/render_view_impl.cc
,
Sep 28 2016
,
Sep 29 2016
Your change meets the bar and is auto-approved for M54 (branch: 2840)
,
Sep 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2623e3573bcbf56d529fb0ea3e401c2f590f7d8c commit 2623e3573bcbf56d529fb0ea3e401c2f590f7d8c Author: Bret Sepulveda <bsep@chromium.org> Date: Thu Sep 29 20:24:11 2016 Fix drop event location being incorrect at hidpi. Only a problem with use-zoom-for-dsf on, but that is now default on Windows and ChromeOS. BUG= 644421 Review-Url: https://codereview.chromium.org/2370523002 Cr-Commit-Position: refs/heads/master@{#421271} (cherry picked from commit 9d8c853ad24d06a02013df4335a230be723c3065) Review URL: https://codereview.chromium.org/2382733004 . Cr-Commit-Position: refs/branch-heads/2840@{#584} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/2623e3573bcbf56d529fb0ea3e401c2f590f7d8c/content/renderer/render_view_impl.cc
,
Oct 5 2016
Tested the same on windows pro 8, win10 and win7 chrome version 54.0.2840.50 using the fiddle http://jsfiddle.net/p6jcvkro/2/ - Observed that the last position of drag over event should be same position as drop position Please find the screenshot Fix works as expected. Hence adding TE-Verified labels
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2623e3573bcbf56d529fb0ea3e401c2f590f7d8c commit 2623e3573bcbf56d529fb0ea3e401c2f590f7d8c Author: Bret Sepulveda <bsep@chromium.org> Date: Thu Sep 29 20:24:11 2016 Fix drop event location being incorrect at hidpi. Only a problem with use-zoom-for-dsf on, but that is now default on Windows and ChromeOS. BUG= 644421 Review-Url: https://codereview.chromium.org/2370523002 Cr-Commit-Position: refs/heads/master@{#421271} (cherry picked from commit 9d8c853ad24d06a02013df4335a230be723c3065) Review URL: https://codereview.chromium.org/2382733004 . Cr-Commit-Position: refs/branch-heads/2840@{#584} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/2623e3573bcbf56d529fb0ea3e401c2f590f7d8c/content/renderer/render_view_impl.cc |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rin...@gmail.com
, Sep 6 2016