Title: [239025] trunk/Tools
Revision
239025
Author
wenson_hs...@apple.com
Date
2018-12-09 23:54:16 -0800 (Sun, 09 Dec 2018)

Log Message

[iOS] DragAndDropTests.RespectsExternalSourceFidelityRankings is flaky
https://bugs.webkit.org/show_bug.cgi?id=192524

Reviewed by Ryosuke Niwa.

This test started failing on certain builds of iOS where UIKit now attempts to reveal the selection by scrolling
(see <rdar://problem/28300343>). This API test simulates two drops from external sources, both from the point
(300, 400) to (100, 300) in window coordinates. On these aforementioned builds of iOS, what happens is that the
first drop inserts text that overflows the editable region by an enormous amount, which creates an extremely
wide selection rect and increases the width of the document; revealing this selection causes the web view to
scroll horizontally, such that the second attempt to simulate a drag from (300, 400) to (100, 300) fails, since
these window coordinates no longer correspond to the drop destination element in the document.

To fix this test, we simply mark the drop destination as `overflow: hidden` to ensure that we don't try and
scroll horizontally after the first drop.

* TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html:

Modified Paths

Diff

Modified: trunk/Tools/ChangeLog (239024 => 239025)


--- trunk/Tools/ChangeLog	2018-12-10 05:30:23 UTC (rev 239024)
+++ trunk/Tools/ChangeLog	2018-12-10 07:54:16 UTC (rev 239025)
@@ -1,3 +1,23 @@
+2018-12-09  Wenson Hsieh  <wenson_hs...@apple.com>
+
+        [iOS] DragAndDropTests.RespectsExternalSourceFidelityRankings is flaky
+        https://bugs.webkit.org/show_bug.cgi?id=192524
+
+        Reviewed by Ryosuke Niwa.
+
+        This test started failing on certain builds of iOS where UIKit now attempts to reveal the selection by scrolling
+        (see <rdar://problem/28300343>). This API test simulates two drops from external sources, both from the point
+        (300, 400) to (100, 300) in window coordinates. On these aforementioned builds of iOS, what happens is that the
+        first drop inserts text that overflows the editable region by an enormous amount, which creates an extremely
+        wide selection rect and increases the width of the document; revealing this selection causes the web view to
+        scroll horizontally, such that the second attempt to simulate a drag from (300, 400) to (100, 300) fails, since
+        these window coordinates no longer correspond to the drop destination element in the document.
+
+        To fix this test, we simply mark the drop destination as `overflow: hidden` to ensure that we don't try and
+        scroll horizontally after the first drop.
+
+        * TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html:
+
 2018-12-08  Daniel Bates  <daba...@apple.com>
 
         Fix lldb_webkit.py following r238771

Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html (239024 => 239025)


--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html	2018-12-10 05:30:23 UTC (rev 239024)
+++ trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html	2018-12-10 07:54:16 UTC (rev 239025)
@@ -14,7 +14,7 @@
             white-space: nowrap;
         }
 
-        #source {
+        #source, #editor {
             overflow: hidden;
         }
 
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to