New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 705984 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 657748



Sign in to add a comment

:hover should match display:contents elements

Reported by r...@opera.com, Mar 28 2017

Issue description

While hovering a node, all elements in the ancestor chain should match :hover. Currently, we walk LayoutObject ancestors, but display:contents elements should also match :hover.

In Firefox, this almost works. They seem to have an invalidation problem. If you select text at the same time as hovering, the text in hover.html goes green.

PS. This is currently behind a flag, so --enable-experimental-web-platform-features is required for testing.

 
hover.html
281 bytes View Download

Comment 1 by eco...@igalia.com, Mar 28 2017

Thanks, rune, looking into it.

Comment 3 by eco...@igalia.com, Mar 28 2017

I'm experimenting with some required cleanup here: https://codereview.chromium.org/2778153003. Seems to work fine locally, waiting for a dry run now.

With that, the test-case doesn't work still. This is at least because of two different issues.

 * Hit testing or hover code seems to skip text nodes for this, so in the test case the hover node that arrives to the document is the body.
 * With an intermediate div, and verifying that the display: contents node is added to the path, the style doesn't yet change. I need to track that down further, but I need to run for today.
Blocking: 657748
Cc: -eco...@igalia.com
Labels: Update-Quarterly
Owner: eco...@igalia.com
Status: Assigned (was: Available)
Project Member

Comment 5 by bugdroid1@chromium.org, Apr 3 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3f2db89d6d660abe00760144e734ccb9963cce2a

commit 3f2db89d6d660abe00760144e734ccb9963cce2a
Author: ecobos <ecobos@igalia.com>
Date: Mon Apr 03 13:30:00 2017

Use the flat tree for hover handling.

Modulo spec debate like[1], this is much simpler and closer to the spec than
what it was implemented.

This doesn't actually fix  issue 705984 , but it's a required cleanup, and I've
verified that the display: contents node is added to the :hover chain (if
there's an intermediate <div>), so I probably need to investigate how hit testing
and style invalidation is done, etc, to track down that bug.

Still this is worth landing IMO.

BUG= 705984 

Review-Url: https://codereview.chromium.org/2778153003
Cr-Commit-Position: refs/heads/master@{#461417}

[modify] https://crrev.com/3f2db89d6d660abe00760144e734ccb9963cce2a/third_party/WebKit/Source/core/dom/Document.cpp

Project Member

Comment 6 by bugdroid1@chromium.org, Apr 5 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ad28574a6bf7b3ddce555b536c6047373b5727ab

commit ad28574a6bf7b3ddce555b536c6047373b5727ab
Author: rune <rune@opera.com>
Date: Wed Apr 05 20:22:35 2017

Allow display:contents elements in hover chain.

Document::updateHoverActiveState walked the shadow-including ancestor
path assuming no layoutObject meant display:none. Changed to walk flat
tree ancestors checking for display:contents style in addition.

ContainerNode::setHovered did not allow hover state to be changed when
setting hovered=true on elements without a layout object. Changed to
allow for display:contents here as well.

R=ecobos@igalia.com
BUG= 705984 

Review-Url: https://codereview.chromium.org/2790133002
Cr-Commit-Position: refs/heads/master@{#462199}

[add] https://crrev.com/ad28574a6bf7b3ddce555b536c6047373b5727ab/third_party/WebKit/LayoutTests/fast/css/hover-display-contents.html
[modify] https://crrev.com/ad28574a6bf7b3ddce555b536c6047373b5727ab/third_party/WebKit/Source/core/dom/ContainerNode.cpp
[modify] https://crrev.com/ad28574a6bf7b3ddce555b536c6047373b5727ab/third_party/WebKit/Source/core/dom/Document.cpp

Comment 7 by r...@opera.com, Apr 5 2017

Status: Fixed (was: Assigned)

Sign in to add a comment