These tests +platform/mac/accessibility/html-slider-indicator.html +platform/mac/accessibility/listbox-hit-test.html +platform/mac/accessibility/iframe-with-title-correct-hierarchy.html which require hit testing do not work with WK2 right now.
<rdar://problem/15710006>
*** Bug 98371 has been marked as a duplicate of this bug. ***
From looking at <http://trac.webkit.org/browser/trunk/Source/WebKit/mac/WebView/WebHTMLView.mm?rev=185021#L4636> and <http://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/mac/AccessibilityControllerMac.mm?rev=165870#L51>, window.accessibilityController.elementAtPoint() expects that the specified coordinates of the point are with respect to the screen coordinate system and ultimately converts them to document ("content") coordinates. But the analogous function in WebKitTestRunner, <http://trac.webkit.org/browser/trunk/Tools/WebKitTestRunner/InjectedBundle/AccessibilityController.cpp?rev=179409#L92>, expects the specified coordinates to be with respect to the document coordinate system (*). We need to teach WebKitTestRunner to convert from screen coordinates to document coordinates. On another note, I'm unclear how we came to the decision to have methods on AccessibilityController and AccessibilityUIElement take and return points with respect to the screen coordinate system as opposed to the document coordinate system. I take it there is value in using screen coordinates? (*) The point is ultimately passed unchanged through to AccessibilityRenderObject::accessibilityHitTest(). And AccessibilityRenderObject::accessibilityHitTest() assumes the point is in document coordinates. The call chain has the form: ... => JSAccessibilityController::elementAtPoint() => AccessibilityController::elementAtPoint() => AccessibilityUIElement::elementAtPoint() => -[WebAccessibilityObjectWrapper accessibilityHitTest:] => AccessibilityScrollView::accessibilityHitTest() => AccessibilityRenderObject::accessibilityHitTest().
(In reply to comment #3) > From looking at > <http://trac.webkit.org/browser/trunk/Source/WebKit/mac/WebView/WebHTMLView. > mm?rev=185021#L4636> and > <http://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/mac/ > AccessibilityControllerMac.mm?rev=165870#L51>, > window.accessibilityController.elementAtPoint() expects that the specified > coordinates of the point are with respect to the screen coordinate system > and ultimately converts them to document ("content") coordinates. But the > analogous function in WebKitTestRunner, > <http://trac.webkit.org/browser/trunk/Tools/WebKitTestRunner/InjectedBundle/ > AccessibilityController.cpp?rev=179409#L92>, expects the specified > coordinates to be with respect to the document coordinate system (*). We > need to teach WebKitTestRunner to convert from screen coordinates to > document coordinates. > > On another note, I'm unclear how we came to the decision to have methods on > AccessibilityController and AccessibilityUIElement take and return points > with respect to the screen coordinate system as opposed to the document > coordinate system. I take it there is value in using screen coordinates? > > (*) The point is ultimately passed unchanged through to > AccessibilityRenderObject::accessibilityHitTest(). And > AccessibilityRenderObject::accessibilityHitTest() assumes the point is in > document coordinates. The call chain has the form: > ... => JSAccessibilityController::elementAtPoint() => > AccessibilityController::elementAtPoint() => > AccessibilityUIElement::elementAtPoint() => -[WebAccessibilityObjectWrapper > accessibilityHitTest:] => AccessibilityScrollView::accessibilityHitTest() => > AccessibilityRenderObject::accessibilityHitTest(). I think we generally want the testing points to be in document coordinates, but i think we may have done it this way so that we could take the value for the origin or the clickPoint and pass that back into the hit test. those points coming out i believe are converted to system coords