[webkit-reviews] review granted: [Bug 172917] [Mac] Implement basic hit testing in the scrolling tree : [Attachment 360691] Patch

[bugzilla-daemon at webkit.org]

Antti Koivisto <koivisto at iki.fi> has granted Simon Fraser (smfr)
<simon.fraser at apple.com>'s request for review:
Bug 172917: [Mac] Implement basic hit testing in the scrolling tree
https://bugs.webkit.org/show_bug.cgi?id=172917

Attachment 360691: Patch

https://bugs.webkit.org/attachment.cgi?id=360691&action=review




--- Comment #53 from Antti Koivisto <koivisto at iki.fi> ---
Comment on attachment 360691
  --> https://bugs.webkit.org/attachment.cgi?id=360691
Patch

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

> Source/WebCore/ChangeLog:22
> +	   Nodes in the scrolling tree implement scrollingNodeForPoint() to
implement hit testing.
> +	   Two helper functions exist to simplify coordinate conversion:
parentToLocalPoint()
> +	   and localToContentsPoint(). Child nodes are hit-testing in reverse
order to find nodes
> +	   hightest in Z first. Only scrolling nodes are returned (not sure if
we'll ever need
> +	   to hit-test non-scrolling nodes). Nodes use
parentRelativeScrollableRect and scroll positions
> +	   to do these point mappings.

It is still bit unclear to me why we want to do it like this. Wouldn't it be
simpler and more robust to hit test in the layer tree, then find the
corresponding ScrollingNode for the layer hit (several approaches for this)?
Does that not work in some case?