[iOS] Precision drop state thrashes when dragging near the top edge of an editable...
authorwenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 12 Jan 2019 00:21:49 +0000 (00:21 +0000)
committerwenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 12 Jan 2019 00:21:49 +0000 (00:21 +0000)
commitd49de1ef40991e8e43ef6bb83fd5007971ba597c
tree2af1ea752aea5e99470a3f50d0582d017a369aea
parentd953188d3378ce6204931df3f8a2efc6e560a91e
[iOS] Precision drop state thrashes when dragging near the top edge of an editable element
https://bugs.webkit.org/show_bug.cgi?id=193364
<rdar://problem/47214117>

Reviewed by Tim Horton.

Source/WebCore:

Add a new helper method on DragCaretController to compute the bounds of the editable element around the drop
caret position. This is either the enclosing form control (in the case of text fields and text areas), or the
highest editable root. See WebKit ChangeLog for more details.

Test: DragAndDropTests.AvoidPreciseDropNearTopOfTextArea

* editing/FrameSelection.cpp:
(WebCore::DragCaretController::editableElementRectInRootViewCoordinates const):
* editing/FrameSelection.h:

Source/WebKit:

On iOS, marking a UIDropProposal as precise offsets the hit-testing location of the drop by a small distance
either upwards or downwards from the actual location of the user's finger. When dragging over an editable
element, WebKit currently marks the drop proposal as precise; however, when dragging over the top edge of an
editable element, what happens is that the hit-testing location is offset to a location outside of the editable
element, which causes us to turn off precision drop mode; subsequently, turning off precision drop mode removes
the offset, which causes us to hit-test within the editable element once again and re-enable precision mode, and
the cycle continues.

In order to mitigate this, bail out of precision drop mode when dragging near the top or bottom edges of the
highest editable root that contains the current drop caret position (or, if the drop caret is inside of a text
form control, use the form control as the editable element instead).

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didPerformDragControllerAction):
* UIProcess/WebPageProxy.h:
(WebKit::WebPageProxy::currentDragCaretEditableElementRect const):
* UIProcess/WebPageProxy.messages.in:
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView dropInteraction:sessionDidUpdate:]):

Avoid precise mode when we're less than 25pt away from the top and bottom edge of the editable element rect.
Since the drag location offset amount is a fixed offset in window coordinates, we first convert this minimum
distance to the content view's coordinate space by dividing by the content scale factor.

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::performDragControllerAction):

Tools:

Add a test to verify that dragging near the top of a textarea element does not flag the drop proposal as
precise, whereas dragging near the middle of the textarea does.

* TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm:
(TestWebKitAPI::TEST):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239881 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore/ChangeLog
Source/WebCore/editing/FrameSelection.cpp
Source/WebCore/editing/FrameSelection.h
Source/WebKit/ChangeLog
Source/WebKit/UIProcess/WebPageProxy.cpp
Source/WebKit/UIProcess/WebPageProxy.h
Source/WebKit/UIProcess/WebPageProxy.messages.in
Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Source/WebKit/WebProcess/WebPage/WebPage.cpp
Tools/ChangeLog
Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm