Bug 111749

Summary: [CSS Regions] Mouse over an element does not trigger :hover state for parent when the element is flowed in a region
Product: WebKit Reporter: Mihai Balan <mibalan>
Component: CSSAssignee: Radu Stavila <stavila>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, eric, esprehn+autocc, glenn, mihnea, rniwa, WebkitBugTracker
Priority: P2 Keywords: AdobeTracked
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 117035    
Bug Blocks: 57312    
Attachments:
Description Flags
Ref-test highlighting the problem
none
More test cases
none
Patch
none
Patch none

Mihai Balan
Reported 2013-03-07 10:01:35 PST
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.
Attachments
Ref-test highlighting the problem (1.18 KB, application/x-zip-compressed)
2013-03-07 10:09 PST, Mihai Balan 		no flags
Details
More test cases (1.45 KB, application/zip)
2013-05-20 23:55 PDT, Mihnea Ovidenie 		no flags
Details
Patch (20.16 KB, patch)
2013-05-23 02:09 PDT, Radu Stavila 		no flags
DetailsFormatted DiffDiff
Patch (33.87 KB, patch)
2013-05-23 07:08 PDT, Radu Stavila 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Mihai Balan
Comment 1 2013-03-07 10:09:27 PST
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
Comment 2 2013-05-20 23:55:21 PDT
Created attachment 202382 [details] More test cases
Radu Stavila
Comment 3 2013-05-23 02:09:06 PDT
Created attachment 202652 [details] Patch
Radu Stavila
Comment 4 2013-05-23 07:08:22 PDT
Created attachment 202707 [details] Patch
Antti Koivisto
Comment 5 2013-05-28 05:25:21 PDT
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 6 2013-05-28 05:42:37 PDT
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 7 2013-05-28 23:56:43 PDT
Comment on attachment 202707 [details] Patch Ok.
WebKit Commit Bot
Comment 8 2013-05-29 00:17:55 PDT
Comment on attachment 202707 [details] Patch Clearing flags on attachment: 202707 Committed r150868: <http://trac.webkit.org/changeset/150868>
WebKit Commit Bot
Comment 9 2013-05-29 00:17:58 PDT
All reviewed patches have been landed. Closing bug.
Eric Seidel (no email)
Comment 10 2013-07-17 11:03:39 PDT
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)
Comment 11 2013-07-17 11:24:45 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.