New issue
Advanced search Search tips

Issue 908815 link

Starred by 1 user
Status: Duplicate
Merged: issue 908750
Owner: ----
Closed: Nov 29
Cc:
viswa.karala@chromium.org
riajiang@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Drag and Drop API not working on DOM elements on top of an iframe

Reported by jo...@instantmagazine.com, Nov 27 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36

Steps to reproduce the problem:
1. Grab the square
2. Hover the square over the box with the video

What is the expected behavior?
Expect to see the block highlighting or changing color. Similar to the one left from the video

What went wrong?
The ondragover and ondragleave events are not being triggered on the element on top of the iframe

Did this work before? Yes 69

Does this work in other browsers? Yes

Chrome version: 70.0.3538.110  Channel: stable
OS Version: OS X 10.14.1
Flash Version: 

It does work when web security is disabled
chrome-70-drag-drop-not-working-with-iframe (1).zip
2.3 KB Download

Comment 1 by woxxom@gmail.com, Nov 27 

FWIW in Windows this test case didn't work for me in all versions of Chrome I've tried, neither in Firefox, but judging by the description it might be same as  bug 908750 . Reporter, could you try exit Chrome and run it with "--disable-features=VizHitTestDrawQuad" command line switch?

Comment 2 by jo...@instantmagazine.com, Nov 27 

Double checked but also on Windows Chrome 70 does work as expected. Windows 10 + Chrome 69 does work (same as OS X). Dragging the square over the DOM element inside the 3 boxes should give a different outcome. See https://codepen.io/jgalama/pen/EOexMo?editors=1111

Disabling the feature VizHitTestDrawQuad makes it work as expected.

Comment 3 by viswa.karala@chromium.org, Nov 27

Labels: Needs-Triage-M70 Needs-Bisect

Comment 4 by viswa.karala@chromium.org, Nov 28

Cc: riajiang@chromium.org viswa.karala@chromium.org
Labels: -Pri-2 -Needs-Bisect RegressedIn-70 Triaged-ET Target-70 Target-71 Target-72 M-71 FoundIn-71 FoundIn-70 FoundIn-72 hasbisect OS-Linux OS-Windows Pri-1
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on chrome reported version# 70.0.3538.110 using Windows-10, Mac 10.14.1 and Ubuntu 14.04, hence providing bisect info

Note: With default chrome settings unable to reproduce the issue but "resetting the flags to default" in chrome://flags then we are able to reproduce the issue. Issue break is seen on 70.0.3538 branch builds, hence providing below manual change log from omahaproxy.

Bisect Info:
================
Good build: 70.0.3538.44
Bad build: 70.0.3538.45

Change Log: https://chromium.googlesource.com/chromium/src/+log/70.0.3538.44..70.0.3538.45?pretty=fuller&n=10000

Note: 
1) Unable to find correct suspect from the above change log, hence marking this issue as Untriaged and requesting someone from Development team help in assigning it to correct suspect.
2) As per comment# 1(issue:  908750 ), CC'ing: Ria Jiang for further inputs on this issue.
3) As we are not sure about the suspect, hence not adding ReleaseBlock-Stable to it.

Thanks

Comment 5 by riajiang@chromium.org, Nov 29

Mergedinto: 908750
Status: Duplicate (was: Untriaged)
►

Sign in to add a comment