[Webkit-unassigned] [Bug 7555] :hover style not applied on hover if its display property is different from original style's

bugzilla-daemon at opendarwin.org bugzilla-daemon at opendarwin.org
Sat Mar 4 13:11:19 PST 2006


http://bugzilla.opendarwin.org/show_bug.cgi?id=7555


darin at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #6828|review?                     |review-
               Flag|                            |




------- Comment #6 from darin at apple.com  2006-03-04 13:11 PDT -------
(From update of attachment 6828)
Since attach() could do arbitrary amounts of work, I think this code could
malfunction if there's a new hover node or active node. For example, a modal
dialog might even run inside the attach().

But I have an idea about how to fix this in a way that's cleaner and more
bulletproof.

We should factor the code to set the hover and active nodes out of
RenderLayer:: updateHoverActiveState. That function could simply decide what
the new nodes should be given the NodeInfo and then call a function in
DocumentImpl to actually change the state of all the bits on the nodes.

After all, the booleans are effectively caches of the hoverNode and activeNode
setting on the document so they should be maintained together.

The code in ElementImpl could then call that same function to restore the hover
and active node before calling attach(). The only strange thing about this is
that it would set the hover and active node to things that don't yet have a
renderer.

After calling attach() it can then call a function that will move the node off
of anything that doesn't have a renderer. That function, too, can be in
DocumentImpl.

That way, all this code to maintain hover and active nodes can be together
inside DocumentImpl, and the flags won't ever be out of sync. with the nodes in
the document.

I think this approach will let you do the bug fix you're doing here and keep
the code a little easier to read.

What do you think?


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list