imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/same-hash.html Is a flaky text failure on iOS and wk1 queues since the test was introduced. HISTORY: https://results.webkit.org/?suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fhtml%2Fbrowsers%2Fhistory%2Fthe-location-interface%2Fsame-hash.html DIFF: --- /Volumes/Data/worker/ios-simulator-15-debug-tests-wk2/build/layout-test-results/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/same-hash-expected.txt +++ /Volumes/Data/worker/ios-simulator-15-debug-tests-wk2/build/layout-test-results/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/same-hash-actual.txt @@ -1,6 +1,6 @@ -PASS Using location.hash = "#te<st" must not reset scroll position +FAIL Using location.hash = "#te<st" must not reset scroll position assert_greater_than: First hash assignment scrolls the iframe expected a number greater than 150 but got 0 PASS Using location.hash = "te<st" must not reset scroll position PASS Using location.hash = "#te%3Cst" must not reset scroll position PASS Using location.hash = "te%3Cst" must not reset scroll position DIFF-URL: https://build.webkit.org/results/Apple-iOS-15-Simulator-Debug-WK2-Tests/r290885%20(1859)/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/same-hash-diff.txt
<rdar://problem/89926580>
Correction, this is not solely happening on iOS queues.
Marking expectations until further investigation can occur.
Not truly a regression, just a WPT test update from upstream. Looking at the output, this likely has to do with some scrolling happening asynchronously when the test expects it not too. As a result, when the test checks the scroll position, sometimes it has scrolled and sometimes it hasn't.
(In reply to Chris Dumez from comment #4) > Not truly a regression, just a WPT test update from upstream. > > Looking at the output, this likely has to do with some scrolling happening > asynchronously when the test expects it not too. As a result, when the test > checks the scroll position, sometimes it has scrolled and sometimes it > hasn't. Ah I see, incorrect starting position, this would mostly be a test order issue then? Or is modifying the test to reset starting position possible?
(In reply to Matteo Flores from comment #5) > (In reply to Chris Dumez from comment #4) > > Not truly a regression, just a WPT test update from upstream. > > > > Looking at the output, this likely has to do with some scrolling happening > > asynchronously when the test expects it not too. As a result, when the test > > checks the scroll position, sometimes it has scrolled and sometimes it > > hasn't. > > Ah I see, incorrect starting position, this would mostly be a test order > issue then? Or is modifying the test to reset starting position possible? Either the test needs to be modified to not wait a little bit for the scrolling position to get updated (which would mean an upstream PR since this is an imported W3C/WPT test, not a WebKit test). Or we really do have a bug and the scroll position is supposed to get updated synchronously here (which would be a WebKit bug but likely not a recent regression).
I have marked this test as a flaky failure while this issue is investigated.
Pull request: https://github.com/WebKit/WebKit/pull/501
Test gardening commit r293787 (250266@main): <https://commits.webkit.org/250266@main> Reviewed commits have been landed. Closing PR #501 and removing active labels.