[CSS Regions] Mouse over an element does not trigger :hover state for parent when the element is flowed in a region

• Component: CSS
• Status: RESOLVED FIXED

[Mihai Balan]

In "normal flow", if an element has a :hover rule, it is applied when moving the mouse over it's children too, even if they are not geometrically inside the box of their parent (e.g. positioned elements, etc.)

However, if the children are flowed in a region while their parent is still in normal flow, the :hover state is not triggered on the parent (when moving the mouse over its children).

If both the parent and it's children are in a named flow, the :hover state gets triggered as usually.

[Mihai Balan]

Created attachment 192035 [details]
Ref-test highlighting the problem

Interactive ref-test highlighting the problem.

The -expected file simulates the out-of-parent rectangle situation via relative positioning.

[Mihnea Ovidenie]

Created attachment 202382 [details]
More test cases

[Radu Stavila]

Created attachment 202652 [details]
Patch

[Radu Stavila]

Created attachment 202707 [details]
Patch

[Antti Koivisto]

Comment on attachment 202707 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=202707&action=review

> Source/WebCore/ChangeLog:10
> +        When searching for the hover ancestor and encountering a named flow thread,
> +        the search will continue with the DOM ancestor of the top-most element
> +        in the named flow thread.

The ChangeLog could use improvements. What happened before? How does this change fix the bug?

> Source/WebCore/rendering/RenderObject.cpp:3047
> +RenderObject* RenderObject::hoverAncestor() const
> +{

Is this function really necessary for all RenderObjects? Could it be in some more specific subclass? (RenderBoxModelObject? RenderBox?)

> Source/WebCore/rendering/RenderObject.cpp:3056
> +    // Skip anonymous blocks. There's no point in treating them as hover ancestors
> +    // and it would also prevent us from continuing the search on the DOM tree
> +    // when reaching the named flow thread.

Why is there "no point"?

[Radu Stavila]

Comment on attachment 202707 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=202707&action=review

>> Source/WebCore/ChangeLog:10
>> +        in the named flow thread.
> 
> The ChangeLog could use improvements. What happened before? How does this change fix the bug?

The initial behaviour would just go up the parent chain, initially reaching the named flow thread and then the render view. As such, it would not reach the DOM parent of the element flowed into the named flow thread.

>> Source/WebCore/rendering/RenderObject.cpp:3047
>> +{
> 
> Is this function really necessary for all RenderObjects? Could it be in some more specific subclass? (RenderBoxModelObject? RenderBox?)

I believe so, since any type of object can reside inside a named flow.

>> Source/WebCore/rendering/RenderObject.cpp:3056
>> +    // when reaching the named flow thread.
> 
> Why is there "no point"?

Hovering is based on the DOM structure and anonymous blocks have no DOM equivalent.

[Antti Koivisto]

Comment on attachment 202707 [details]
Patch

Ok.

[WebKit Commit Bot]

Comment on attachment 202707 [details]
Patch

Clearing flags on attachment: 202707

Committed r150868: <http://trac.webkit.org/changeset/150868>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Eric Seidel (no email)]

We're seeing this as a possible regression in Chromium wrt handling of :hover on display: block:
https://code.google.com/p/chromium/issues/detail?id=253472

Still investigating, just a heads up.

[Eric Seidel (no email)]

This was verified to cause :hover to stop working on display: block elements in Chromium, and a revert patch has been posted:
https://codereview.chromium.org/19660002

I don't know if this caused the same regression in WebKit.  Just wanted you to know.