Bug 230127 – [ iOS ] editing/selection/ios/select-text-under-hidden-subframe.html is timing out

• Status: NEW
• Component: New Bugs

editing/selection/ios/select-text-under-hidden-subframe.html

Is timing out on iOS.

History: https://results.webkit.org/?suite=layout-tests&test=editing%2Fselection%2Fios%2Fselect-text-under-hidden-subframe.html

It is showing up on EWS as a pre-existing failure.

Result page: https://build.webkit.org/results/Apple-iPadOS-14-Simulator-Release-WK2-Tests/r282223%20(2085)/results.html#

Diff:

--- /Volumes/Data/worker/ipados-simulator-14-release-tests-wk2/build/layout-test-results/editing/selection/ios/select-text-under-hidden-subframe-expected.txt
+++ /Volumes/Data/worker/ipados-simulator-14-release-tests-wk2/build/layout-test-results/editing/selection/ios/select-text-under-hidden-subframe-actual.txt
@@ -1,13 +1,11 @@
+FAIL: Timed out waiting for notifyDone to be called
+
 Verifies that text can be selected using text interaction gestures, even when it is fully covered by a hidden subframe. To manually run the test, tap to focus and double tap again to select 'Banana'; then long press to select 'Apple'.
 
 On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
 
 
 PASS getSelection().toString() became 'Banana'
-PASS getSelection().toString() became 'Apple'
-PASS successfullyParsed is true
-
-TEST COMPLETE
 Apple
 Banana

Looking at the history. it appears that the timeout started somewhere between r282205 and r282199

[Radar WebKit Bug Importer]

<rdar://problem/82945383>

Since spades are not available anymore after 9/2 for iOS, I cannot reproduce locally to find out the regression point.

[Cameron McCormack (:heycam)]

https://trac.webkit.org/changeset/282202/webkit made some changes to layout when offsetTop/offsetLeft are inspected, which this test does.

[Wenson Hsieh]

This doesn't seem to reproduce locally on trunk, on iOS 15 (it looks like our internal iOS 15 test runners are not timing out, either).

It might be nice to still figure out why this change, but maybe we can just set expectations for iOS 14 in the meantime?

(In reply to Wenson Hsieh from comment #5)
> This doesn't seem to reproduce locally on trunk, on iOS 15 (it looks like
> our internal iOS 15 test runners are not timing out, either).
> 
> It might be nice to still figure out why this change, but maybe we can just
> set expectations for iOS 14 in the meantime?

Marked test expectations here: https://trac.webkit.org/changeset/282244/webkit