[webkit-reviews] review requested: [Bug 6844] elementAtPoint returns the list when the point is over a list marker : [Attachment 6819] patch

[bugzilla-request-daemon at opendarwin.org]

Justin Garcia <justin.garcia at apple.com> has asked  for review:
Bug 6844: elementAtPoint returns the list when the point is over a list marker
http://bugzilla.opendarwin.org/show_bug.cgi?id=6844

Attachment 6819: patch
http://bugzilla.opendarwin.org/attachment.cgi?id=6819&action=edit

------- Additional Comments from Justin Garcia <justin.garcia at apple.com>
RenderListMarker::nodeAtPoint was only setting NodeInfo's innerNode.  That was
enough to get the list item's mouse events firing over the list marker, but not
enough to fix elementAtPoint, since elementAtPoint uses NodeInfo's
innerNonSharedNode to populate the dictionary that it returns.

This change calls RenderObject::setInnerNode(), which handles setting both the
innerNode and the innerNonSharedNode.  Since RenderObject::setInnerNode()
assumes that it is being called from the renderer who's element is the inner
node, I needed to call it from inside RenderListItem::nodeAtPoint.

elementAtPoint is used to determine the drag operation that will be performed
when something is dropped over a given point.  So, to test my fix, I wrote a
test that drags some text and drops it over the list marker.  This required
three fixes to DumpRenderTree:
First, when I added DumpRenderTree's WebView to a window, I didn't have the
eventSender send the window number along with the event.
Second, I always call performDragOperation on the destination in
DumpRenderTree.  If the WebView doesn't want to perform a drag operation, it
won't, but it needs to be asked to try or else it gets into a bad state and
asserts fire.
Third, dragging tests in particular, and tests that use the eventSender in
general, often need to pause in order for some series of mouse moves and clicks
to register as a particular operation.	A drag operation will only kick off for
example, if the mouse is held down for a split second on the selected content,
otherwise it will turn into a create-selection operation.  I didn't want to add
explicit delays to layout tests (1 full second is needed after a double click
to make the next mousedown a drag-start and not a triple-click!).  So, I added
a leapForward method to the eventSender, that adds the given offset to the
timestamp of each event sent thereafter.