New issue
Advanced search Search tips

Issue 630726 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Compat



Sign in to add a comment

:hover is applied during drag-n-drop operation (CSS)

Reported by cyril.au...@gmail.com, Jul 22 2016

Issue description

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

Example URL:
https://jsfiddle.net/crl/x59r9b9w/4/

Steps to reproduce the problem:
1. https://jsfiddle.net/crl/x59r9b9w/4/
2. http://recordit.co/C1NwNItCU3
3. 

What is the expected behavior?
in the video http://recordit.co/C1NwNItCU3 I drag the item 3, and after a few movements :hover is applied to the item 1.

It shouldn't

What went wrong?
:hover applied to an element while in a drag operation

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.21  Channel: dev
OS Version: 10.0
Flash Version: Shockwave Flash 22.0 r0

Firefox doesn't have this issue
 

Comment 1 by b...@chromium.org, Jul 25 2016

Components: Blink>CSS
Labels: Needs-Bisect OS-Linux
Status: Untriaged (was: Unconfirmed)
Test team, check whether this is a regression please.
Labels: -Needs-Bisect m054 OS-Mac
Tested this issue on Windows 10 using older versions of chrome M35-35.0.1898.0 & M49-49.0.2623.47 and observed the element ID's are not visible on these versions to test this issue.

So tested it on M51-51.0.2704.106 and observed the same behavior as seen on M52-53.0.2785.21 as well. Considering this issue is a non-regression one and marking it as untriaged.

Thanks!
Labels: -m054 M-54
it hard to reproduce, I tried again the jsfiddle, but didn't manage to do it (maybe it happens with a memory leak)
Status: Available (was: Untriaged)
Labels: Update-Quarterly Hotlist-Interop

Comment 8 by shend@chromium.org, Oct 31 2017

Components: -Blink>CSS Blink>Input
Can still reproduce this sometimes on 64.0.3253.0 Linux, but with item 4 being erroneously hovered. Redirecting to input team as the computed style seems to be applied correctly.
I can reproduce this very reliably on 62.0.3202.89 Linux and 62.0.3202.94 macOS. It's always the item taking the dragged element position amongst siblings that erroneously find it's hovered state triggered.
dnd-hover-fiddle.mp4
569 KB View Download
Labels: Needs-Feedback
Just to add a data point. For simple pages like this Chrome does not hover any underlying element.
http://jsfiddle.net/agt4wtyd/10/

So we are missing something in that given example. Do you happen to have a smaller example by any chance so it is easier to get into the bottom of this issue?
Yes! here it is: https://jsfiddle.net/crl/x59r9b9w/22/ much simpler version, same hover issue on Chrome (that works on Firefox)
The issue can also sometimes happen on Firefox as well https://imgur.com/a/LcMoS8Q


Sign in to add a comment