imported/w3c/web-platform-tests/FileAPI/url/url-in-tags.window.html Is flaky failing on macOS wk1. History: https://results.webkit.org/?suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2FFileAPI%2Furl%2Furl-in-tags.window.html Diff: --- /Volumes/Data/worker/bigsur-debug-applesilicon-tests-wk1/build/layout-test-results/imported/w3c/web-platform-tests/FileAPI/url/url-in-tags.window-expected.txt +++ /Volumes/Data/worker/bigsur-debug-applesilicon-tests-wk1/build/layout-test-results/imported/w3c/web-platform-tests/FileAPI/url/url-in-tags.window-actual.txt @@ -1,5 +1,7 @@ + +Harness Error (TIMEOUT), message = null PASS Blob URLs can be used in <script> tags PASS Blob URLs can be used in iframes, and are treated same origin -PASS Blob URL fragment is implemented. +TIMEOUT Blob URL fragment is implemented. Test timed out Though I was not able to reproduce the failure on my local machine due to technical issues, it looks like it started at https://trac.webkit.org/changeset/280824/webkit from the history.
<rdar://problem/81873956>
Updated test expectations https://trac.webkit.org/changeset/280994/webkit
From the radar, the suspicion is that https://trac.webkit.org/changeset/280824/webkit caused the flakiness.
I am able to reproduce the flaky timeout with WK1.
I see, before r280824, this subtest was timing out. In r280824, it stopped timing out for me so I rebaselined the test. However, it seems the subtest is still flakily timing out for WK1.
(In reply to Chris Dumez from comment #5) > I see, before r280824, this subtest was timing out. In r280824, it stopped > timing out for me so I rebaselined the test. However, it seems the subtest > is still flakily timing out for WK1. What this subtest does it trying to load a Blob URL with a fragment identifier in an iframe and check that we're getting a scroll event (because we should have scrolled to the element with the identifier matching the fragment). The test was reliably timing out before r280824 because we would create a new Blob URL and the new Blob URL would be missing the fragment. After r280824, we stopped loosing the fragment of the Blob URL since we keep using the original Blob URL. The test started passing for WK2 at least (and flakily for WK1). However, the WK1 flakiness doesn't seem related to blob support. I added some logging and when the test times out, I see that: - frame document URL is: blob:http://localhost:8800/35d0da6b-c699-4906-9a9a-8eed3fdb876b#block2 (which is correct and has the fragment). - frame.contentDocument.documentElement.innerHTML is: ``` <head><meta charset="utf-8"> <style>body { margin: 0; } .block { height: 5000px; }</style> </head><body> <a id="block1"></a><div class="block"></div> <a id="block2"></a><div class="block"></div></body> ``` so the blob properly loaded in the iframe. However, frame.contentWindow.scrollY is 0, meaning that WK1 does not reliably scroll in this test even though the content is correct and the URL contains the fragment. Seems like a WK1 scrolling issue, not a Blob issue and not really a regression from r280824. r280824 merely enabled the subtest to run by fixing the Blob URL bug.