[Webkit-unassigned] [Bug 40197] Enhance the hit testing to take a rectangle instead of a point

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jun 10 10:40:05 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=40197





--- Comment #9 from Grace Kloba <klobag at gmail.com>  2010-06-10 10:40:01 PST ---
Thanks Antonio to provide another patch. Here is what I thought.

The difference between the point with a padding or rectangle is just name difference. We should be easily to reach agreement with which direction we want to take. I don't have the strong preference. The reason I chose to use point with a padding is that it preserves the old code. So less changes to make. And I think it matches what happened on a mobile device. When user touches the screen, it is a point with a fuzzy size.

The big difference I see is as following.

In the first patch I provided, the traversing for nodeAtPoint is not stopped when the "fat" point intersects with the node bounds. The traversing only stops when the "fat" point is fully enclosed by the node bounds. In the latter patch Antonio provided, if I understand correctly, the traversing breaks when the rectangle intersects with the node bounds.

Here is an example,

<div id="a">
  <div id="b">
    <div id="c"> one </div>
    <div id="d"> two </div>
  </div>
  <div id="e"> three
  </div>
</div>

assuming the point is in-between "one" and "two", and the rectangle covers half "one" and half "two".

With the first patch, the returned node list will contain the nodes in this order, "d" "c" "b". When we detect the "fat" point intersects with "d", we continue the search as the "fat" point is not fully contained by "d". We found "c", and then go back to hit test "b"'s background. Now the "fat" point is fully contained. The search stops.

If I read the latter patch correctly, the nodes returned will be in this order, "d" "b" "a". When the rectangle intersects with "d", it returned. Its parent "b" and "a" are added into the list.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list