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
<rdar://problem/82945383>
Since spades are not available anymore after 9/2 for iOS, I cannot reproduce locally to find out the regression point.
https://trac.webkit.org/changeset/282202/webkit made some changes to layout when offsetTop/offsetLeft are inspected, which this test does.
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