NEW 229058
[ Mac wk1 ] imported/w3c/web-platform-tests/FileAPI/url/url-in-tags.window.html is flaky failing 
https://bugs.webkit.org/show_bug.cgi?id=229058
Summary [ Mac wk1 ] imported/w3c/web-platform-tests/FileAPI/url/url-in-tags.window.ht...
ayumi_kojima
Reported 2021-08-12 16:27:53 PDT
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.
Attachments
Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2021-08-12 16:28:52 PDT
<rdar://problem/81873956>
ayumi_kojima
Comment 2 2021-08-12 16:32:12 PDT
Updated test expectations https://trac.webkit.org/changeset/280994/webkit
Chris Dumez
Comment 3 2021-08-13 15:37:27 PDT
From the radar, the suspicion is that https://trac.webkit.org/changeset/280824/webkit caused the flakiness.
Chris Dumez
Comment 4 2021-08-13 16:10:54 PDT
I am able to reproduce the flaky timeout with WK1.
Chris Dumez
Comment 5 2021-08-13 16:17:44 PDT
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.
Chris Dumez
Comment 6 2021-08-13 16:37:32 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.