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.
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.
Created attachment 202382 [details] More test cases
Created attachment 202652 [details] Patch
Created attachment 202707 [details] Patch
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"?
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.
Comment on attachment 202707 [details] Patch Ok.
Comment on attachment 202707 [details] Patch Clearing flags on attachment: 202707 Committed r150868: <http://trac.webkit.org/changeset/150868>
All reviewed patches have been landed. Closing bug.
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.
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.