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

Issue metadata

Status: Fixed
Owner: ----
Closed: Jun 2013
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

:hover is not applied to projected text nodes

Project Member Reported by, May 29 2013

Issue description

Version: r151203

What steps will reproduce the problem?
1. Open <>
2. Hover over the "Top-level text"
3. Then hover over the "Nested text"

What is the expected output? What do you see instead?

I expect the button:hover rule to be applied regardless of which piece of text I'm hovering over. All the text should be purple.

Instead, when hovering over "Top-level text" the text is black.

The difference between "Top-level text" and "Nested text" is that "Top-level text" is a projected text node, and "Nested text" is a projected element.
dfreedm reports that :active is broken too: <>

Comment 2 by, May 30 2013

I've just investigated the issue.

Document::updateHoverActiveState() updates hover status. However the code doesn't check a hovered node.

(1) When hover over the "Top-level text", the hovered node is a text node and the hovered element is a shadow host, i.e. <div id="h">

(2) When hover over the "Nested text", the hovered node and element is the same, <span>.

(1) means, the button is not hovered. So all the text is black.

I' m now creating a patch for fixing this issue.

Comment 3 by, May 30 2013

Status: Started

Comment 4 by, May 30 2013

I wrote a wrong comment.

(2) When hover over the "Nested text", the hovered node and element is the same, <span>.

(2) When hover over the "Nested text",  the hovered element is <span> and the hovered node is the text contained by the <span>.

Comment 5 Deleted

Comment 6 Deleted

Comment 7 by, May 30 2013

I uploaded a WIP patch in for fixing :hover.

Comment 8 by, May 31 2013

The WIP patch causes :active buggy.
I'm still working on fixing this.

Labels: hotlist-toolkit
A dev sent a very similar example as an issue to the Polymer mailing list, and noted that <button><content></content></button> will never display the <button>'s downstate if the inserted text node is clicked.
For reference:
Thank you for information. I will check

I checked. After applying my patch, the example: seemes to work correctly.

tasak, could you also check the clicking behavior? Jan Miksovsky of QuickUI mentioned this on polymer-dev:

"FWIW, this doesn't appear to be just about text nodes. Even when the content includes a child like a span, the result still does not behave as expected. E.g., in the jsBin referenced in the bug you cite, clicking on the nested span does cause the button to react — but the button's mouse-down appearance toggles on each click, rather than resetting each time on mouse up."

Let me know if you have questions.
Yeah, I agree that the clicking behavior is still buggy after applying my patch.

I need the patch in

Because of insertion point's reattach, we cannot correctly make elements, which are direct children of shadow host and are distributed into some insertion point, active.

When we click the element, the element is sometimes immediately detached and is made inactive and not-hover.

Comment 15 by, Jun 10 2013

I'm now trying to land my patch by using cq.

Project Member

Comment 16 by, Jun 10 2013

The following revision refers to this bug:

r152132 | | 2013-06-10T13:57:10.871941Z

Changed paths:

HitTestResult::innerElement should check its parent node for rendering and styling.

Suppose that text nodes are direct chilren of a shadow host and projected.
If hover over the text nodes, HitTestResult::innerElement should be an element in the shadow dom tree, not the shadow host.

Since innerElement() is only used for Document::updateHoverActiveState (in EventHandler.cpp and Document.cpp), we can modify HitTestResult::innerElement.

To avoid an element in shadow dom tree via Docuemnt.activeElement, use ancestorInThisScope in updateHoverActiveState.

BUG= 244869 

Review URL:

Comment 17 by, Jun 11 2013

Status: Assigned
I fixed some part of this issue. So the repro case is fixed.

However, the issue: "Even when the content includes a child like a span, the result still does not behave as expected. " still exists. I need's patch.

So I will keep monitoring After the patch is landed, I will check this issue again and change its status.

Comment 18 by, Jun 11 2013

Blockedon: chromium:234801

Comment 19 by, Jun 17 2013

Since was landed, I will check this issue.

Comment 20 by, Jun 17 2013

Blockedon: -chromium:234801
Status: Fixed
The layout test that I added by r152132 (fast/dom/shadow/hover-active-drag-distributed-nodes.html) passes now.

So I think, this issue is fixed. Would you verify this?
Assign to me: for reachout.
Owner: ----
Reached out for confirmation.

Sign in to add a comment