Hover state doesn't trigger if a class with :hover is not applied at element creation, but later
Reported by
harab...@gmail.com,
Nov 15 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36 Steps to reproduce the problem: 1. https://jsfiddle.net/cnd1cnh5/3/ 2. hover over the gray box 3. it's background won't change to blue What is the expected behavior? The background should be blue What went wrong? If a class with a defined pseudo-class :hover is applied a few milliseconds later after the <div> was created it won't work. Although, inspecting that element and changing it's hover state from dev tools will make it hoverable. Did this work before? Yes Does this work in other browsers? Yes Chrome version: 62.0.3202.89 Channel: stable OS Version: Linux Mint 18.1 MATE 64-bit Flash Version: Thank you for looking into it!
,
Nov 15 2017
Doesn't repro on Mac using chrome stable 61.0.3163.100 or chrome canary 64.0.3269.0
,
Nov 16 2017
"Able to reproduce the issue on the reported chrome version 62.0.3202.89, As the issue is not seen on the M-64 (64.0.3260.2) using Ubuntu 14.04, Windows 10 and Mac 10.12.6. Reverse Bisect info: ------------------------------------- Good Build : 63.0.3226.0 Revision: 504841 Bad Build: 63.0.3225.0 Revision: 504540 You are probably looking for a change made after 504560 (known good), but no later than 504561 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/a9ba55c8571ab0d2624c83d413ccc7215a185f51..9f0c480da9cb188c82e16e6c6751875a60a114cf Reviewed-on: https://chromium-review.googlesource.com/684186 Suspecting the same. @treib: Please confirm the issue and help in re-assigning if it is not related to your change. Unable to assign to rune@opera.com hence assigning to treib@ Note: Adding label RBS, as it seems to be a recent regression. Please feel free to remove the same if not appropriate. Thanks!"
,
Nov 16 2017
,
Nov 16 2017
So this is working in 63 and 64. For 62, I've been looking at the git log and we need to either: 1. Revert multiple commits on 62. 2. Cherry-pick multiple commits from master. 3. Prepare a new commit which makes 62 end up with the exact same code as on master.
,
Nov 16 2017
futhark@, We are approaching M63 stable release in 2 weeks (~5th Dec), so i don't think we still need this fix for M-62? Thank you!
,
Nov 16 2017
No, I don't think it's worth doing for 62. I haven't tested 63 myself, but comment #3 says we're good on 63. Marking as fixed.
,
Nov 20 2017
Issue 780481 has been merged into this issue.
,
Nov 20 2017
Issue 786956 has been merged into this issue.
,
Nov 24 2017
Issue 788094 has been merged into this issue.
,
Nov 27 2017
,
Dec 7 2017
Issue 792661 has been merged into this issue. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by shend@chromium.org
, Nov 15 2017Status: Untriaged (was: Unconfirmed)