hover css applied via data attribute stops working if the mouse leaves the page
Reported by
threepoi...@gmail.com,
Aug 20 2016
|
|||||
Issue description
Chrome Version : 52.0.2743.116 (Official Build) (64-bit)
os: OS X El Capitan 10.11.5 (15F34)
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari: OK Version 9.1.1 (11601.6.17)
Firefox: OK 47.0.1
What steps will reproduce the problem?
(1) open attached file
(2) hover over the word 'one'
What is the expected result?
hovering over 'one' should add change the background color to red.
What happens instead?
after the first hover, subsequent hovering over the element doesn't change the background color.
Please provide any additional information below. Attach a screenshot if
possible.
This was first reported here - https://github.com/threepointone/glamor/issues/20
This is a specific combination that seems to trigger this bug.
- css is applied via data-attribute selectors. using class names / ids doesn't reproduce the bug
- a media query is present on the page. if the media query rule is removed, this bug doesn't manifest.
,
Aug 20 2016
A non-invasive workaround is to use `[data-abc]:hover:nth-child(n) {...}` instead of `[data-abc]:hover {...}`
I have no idea *why* it fixes this bug, of course.
,
Aug 22 2016
Able to reproduce this on the latest stable(52.0.2743.116) and the latest canary(54.0.2836.0) on Windows-10, Mac OS 10.11.6 and Linux Ubuntu 14.04. This is a regression issue broken in M-31. Last good build: 31.0.1650.25 First bad build: 31.0.1650.26 Changelog: https://chromium.googlesource.com/chromium/src/+log/31.0.1650.25..31.0.1650.26?pretty=fuller&n=10000 Blink changelog: https://chromium.googlesource.com/chromium/blink/+log/4f592e282aaf6efefd18cdb05e4c99f221078794..81ab6100c0f1e8a8d2aad056566d28a72ca83d15?pretty=fuller&n=10000 leviw@: Could you please take a look at this and provide more inputs on this.
,
Aug 23 2016
leviw no longer works on the blink project, assigning to meade@ to route.
,
Aug 23 2016
I'm pretty surprised by how old the versions are found in the bisect! Rune, do you know who the right person to work on this would be?
,
Aug 23 2016
My initial guess would be incorrect style sharing. I can take a look ...
,
Aug 23 2016
If you swap the order of which div gets the attribute, hover never works. Pretty sure this must be style-sharing.
,
Aug 23 2016
setAffectedByHover on ComputedStyle will not be set on the shared one, hence we will never consider the element with the attribute for hover when sharing style with the sibling.
,
Aug 23 2016
Doesn't affect selectors like .class:hover since we compare all classes for style sharing, while we just compare matched rules for attribute rules.
,
Aug 23 2016
Thanks for diving in, that led me to a simpler workaround for the bug too. Adding this to the very top of the stylesheet -
:hover { cursor: initial; }
- fixes the bug. Would you know if there's a performance hit / drawback to the above? anything better? Please, and thank you.
,
Aug 23 2016
That selector will trigger a recalc for every element which goes in/out of the hover chain.
Check the inspector timeline with/without the universal :hover below. Without the first hover rule, you'll never see more than 2 elements per style recalc, but with it you'll see 12 element recalcs hovering in and out of the document.
<!DOCTYPE html>
<style>
:hover { background: initial; }
body:hover { background-color: green; }
</style>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hover me</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
,
Aug 24 2016
,
Aug 25 2016
CL landed.
,
Aug 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b2aee8879058a6a85104073c38868e4edd66b628 commit b2aee8879058a6a85104073c38868e4edd66b628 Author: rune <rune@opera.com> Date: Thu Aug 25 00:33:57 2016 Consider pseudo classes as matching for shared style rejection. The user action pseudo classes rely on affectedBy bits to be correctly set on ComputedStyle in order to recalculate style for such changes later on. If two elements may otherwise share style, but will have the affectedBy bits set differently, they may not share style. Example: <style>[attr]:hover {}</style> <div></div> <div attr></div> The second div may share style with the first one when none of them is hovered. However, matching the selector against the first div will fail on the attribute selector before we try to match :hover, hence the flag for affectedByHover will not be set. If we share that ComputedStyle object with the second div, hovering the second div later will have no effect. Instead we always match :hover/:active/:focus/:-webkit-drag when matching rules for style sharing (attribute and sibling rules). That will lead to the attribute selector in the example above to match which will cause style sharing to be rejected for the second div. R=meade@chromium.org BUG= 639561 Review-Url: https://codereview.chromium.org/2272683002 Cr-Commit-Position: refs/heads/master@{#414221} [modify] https://crrev.com/b2aee8879058a6a85104073c38868e4edd66b628/third_party/WebKit/Source/core/core.gypi [modify] https://crrev.com/b2aee8879058a6a85104073c38868e4edd66b628/third_party/WebKit/Source/core/css/CSSSelector.h [modify] https://crrev.com/b2aee8879058a6a85104073c38868e4edd66b628/third_party/WebKit/Source/core/css/SelectorChecker.cpp [modify] https://crrev.com/b2aee8879058a6a85104073c38868e4edd66b628/third_party/WebKit/Source/core/css/resolver/ElementResolveContext.h [modify] https://crrev.com/b2aee8879058a6a85104073c38868e4edd66b628/third_party/WebKit/Source/core/css/resolver/SharedStyleFinder.h [add] https://crrev.com/b2aee8879058a6a85104073c38868e4edd66b628/third_party/WebKit/Source/core/css/resolver/SharedStyleFinderTest.cpp |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by threepoi...@gmail.com
, Aug 20 2016213 bytes
213 bytes View Download