Title: [249226] trunk/Tools
Revision
249226
Author
wenson_hs...@apple.com
Date
2019-08-28 17:01:03 -0700 (Wed, 28 Aug 2019)

Log Message

WKAttachmentTests.DropFolderAsAttachmentAndMoveByDragging fails in some iOS simulator configurations
https://bugs.webkit.org/show_bug.cgi?id=201241
<rdar://problem/54317588>

Reviewed by Tim Horton.

For reasons that are still unknown, it's possible for iOS 13 simulators to get into a state where the IPC
communication delay between the web and UI processes can become extraordinarily long. Under these circumstances,
the drag and drop harness fails to simulate a drop, since it ends up firing all scheduled calls to
-dropInteraction:sessionDidUpdate: before the first response from the web process arrives in the UI process, so
it believes that the web view has rejected the drop from being handled.

Instead, make the drag and drop simulator robust by ensuring a presentation update between drop session updates,
to make sure that the web process has had time to send a response after each update.

* TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm:
(-[DragAndDropSimulator _advanceProgress]):

Modified Paths

Diff

Modified: trunk/Tools/ChangeLog (249225 => 249226)


--- trunk/Tools/ChangeLog	2019-08-28 23:11:17 UTC (rev 249225)
+++ trunk/Tools/ChangeLog	2019-08-29 00:01:03 UTC (rev 249226)
@@ -1,3 +1,23 @@
+2019-08-28  Wenson Hsieh  <wenson_hs...@apple.com>
+
+        WKAttachmentTests.DropFolderAsAttachmentAndMoveByDragging fails in some iOS simulator configurations
+        https://bugs.webkit.org/show_bug.cgi?id=201241
+        <rdar://problem/54317588>
+
+        Reviewed by Tim Horton.
+
+        For reasons that are still unknown, it's possible for iOS 13 simulators to get into a state where the IPC
+        communication delay between the web and UI processes can become extraordinarily long. Under these circumstances,
+        the drag and drop harness fails to simulate a drop, since it ends up firing all scheduled calls to
+        -dropInteraction:sessionDidUpdate: before the first response from the web process arrives in the UI process, so
+        it believes that the web view has rejected the drop from being handled.
+
+        Instead, make the drag and drop simulator robust by ensuring a presentation update between drop session updates,
+        to make sure that the web process has had time to send a response after each update.
+
+        * TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm:
+        (-[DragAndDropSimulator _advanceProgress]):
+
 2019-08-28  Megan Gardner  <megan_gard...@apple.com>
 
         Null check webFrame when creating a print preview to prevent a crash.

Modified: trunk/Tools/TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm (249225 => 249226)


--- trunk/Tools/TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm	2019-08-28 23:11:17 UTC (rev 249225)
+++ trunk/Tools/TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm	2019-08-29 00:01:03 UTC (rev 249226)
@@ -624,6 +624,7 @@
         break;
     case DragAndDropPhaseEntered: {
         _lastKnownDropProposal = [[_webView dropInteractionDelegate] dropInteraction:[_webView dropInteraction] sessionDidUpdate:_dropSession.get()];
+        [_webView waitForNextPresentationUpdate];
         if (![self shouldAllowMoveOperation] && [_lastKnownDropProposal operation] == UIDropOperationMove)
             _lastKnownDropProposal = adoptNS([[UIDropProposal alloc] initWithDropOperation:UIDropOperationCancel]);
         break;
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to