[PATCH] various nodeAtPoint() fixes

[Dirk Mueller]

On Sam, 13 Jul 2002, Germain Garand wrote:

> I've dived since a week into nodeAtPoint's internals to solve a number of problems
>  with mouse hovering and link detection.

Very nice! I'm quite impressed by the precise analysis and the patch!

> 
> - 1°: relative coordinates change don't propagate recursively to childrens.
> (I posted this last week on kfm-devel but noone replied so it's still pending)

Yes, this was partly intended. I think I remember an interaction with 
absolute positioned containers in relative positioned parents. I have to 
reconstruct the testcase again, for now your change does make sense to 
me, perhaps the old reason for this code line was already fixed in an 
earlier rewrite. 


> - 2°: on the same line, the test for !child->isPositioned() need to be !child->isSpecial()
> (I do know it was changed in r1.171, but please read on.. there is more on this later)

There is another problem here.. the paint order is different than usual for 
floats, see the similiar hacks in renderflow. Therefore floats are 
"special Specialobjects" ( I really hate the name as well). 
Will think about this more. Of course you need very evil cases where the 
paint order of floats vs other elements matters, but this is already found 
on many webpages ;-)

> So Link B will have the hand cursor, but hover will only be triggered if you hover the
> white, non-covered part, of Link B
> 
> Example: 
> ----------
> http://www.w3.org/Style/CSS
> 
> Here, you can't hover "CSS Test Suites" at all, because it's totally covered by transparent containers.
> "What's new" only light up when you hover on the middle region, that is : between the invisible 
> containers of "Learning CSS" and "Specs".
> 
> Now the rationale behind my patch :
> --------------------------------------------
> - All the point of having an innerNode is "there can be only one hovered branch at a time,
>  and one active container if it's a click event".
> - Thus there's no point in selecting an innerNode that has no "hasHover" or "hasActive", better wait until :
>   A) we encounter an URLElement (and we give it the innerNode)
> or
>  B) we encounter a better innerNode, with hover or active.
> or
>  C) we default to the root node.
> 
> This doesn't change the logic : it's just about being smarter about the choice of innerNode.
> 
> +        if (!info.innerNode() && (isRoot() || (style() && style()->hasHover()) || (info.active() && style()->hasActive())))
>              info.setInnerNode(element());
> [...]
>                      info.setURLElement(p->element());
> +                    if (!info.innerNode())
> +                        info.setInnerNode(element());

I like the idea, however the implementation doesn't catch the case where an 
event listener is registered on the innermost node. 

I know your patch is emulating IE's behaviour - which is sort of flawed 
(they mainly did this for performance reasons is my bet) because there is 
nothing "special" about anchor elements in the xml / css world, unlike in 
HTML of course. 

Personally i think khtml is behaving correct in this case, although it is 
very annoying for the example page you mentioned (I've spend some hours on 
that page already)

I'll investigate this a bit more. 


Thanks for your patch, 

Dirk