Bug 242270

Summary: REGRESSION (March 2022): [ iOS Debug ] fast/encoding/char-after-fast-path-ascii-decoding.html is a flaky failure
Product: WebKit Reporter: Karl Rackler <rackler>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: ap, darin, sabouhallawa, webkit-bot-watchers-bugzilla, webkit-bug-importer
Priority: P2 Keywords: EasyFix, InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   

Description Karl Rackler 2022-07-01 15:01:09 PDT 
Description:
fast/encoding/char-after-fast-path-ascii-decoding.html

The first failure that I saw on the dashboard was on 4/2/2022 at 249160@main.  This test has been flaky for its entire history on the dashboard.

History:
https://results.webkit.org/?suite=layout-tests&test=fast%2Fencoding%2Fchar-after-fast-path-ascii-decoding.html&platform=ios&limit=50000&style=debug

Diff:
--- /Volumes/Data/worker/ios-simulator-15-debug-tests-wk2/build/layout-test-results/fast/encoding/char-after-fast-path-ascii-decoding-expected.txt
+++ /Volumes/Data/worker/ios-simulator-15-debug-tests-wk2/build/layout-test-results/fast/encoding/char-after-fast-path-ascii-decoding-actual.txt
@@ -1,2 +1,2 @@
 
-ABCDEFGH‚‚
+
Comment 1 Radar WebKit Bug Importer 2022-07-01 15:02:27 PDT 
<rdar://problem/96316372>
Comment 2 Karl Rackler 2022-07-01 15:04:59 PDT 
I have marked this test as a flaky failure while this issue is investigated.
Comment 3 EWS 2022-07-01 15:09:49 PDT 
Test gardening commit 252073@main (68c924e054f4): <https://commits.webkit.org/252073@main>

Reviewed commits have been landed. Closing PR #2013 and removing active labels.
Comment 4 Alexey Proskuryakov 2022-07-04 11:25:17 PDT 
The test fails more frequently than it passes. It became dramatically more flaky a few months ago, in early March 2022.

Looking at the test, it incorrectly assumes that waiting for 500 ms guarantees that a subframe would be loaded. Why didn't we just use onload here? Also, the test doesn't need waitUntilDone/notifyDone, as tests complete after the load event by default.

A more interesting question that we will probably will never be able to answer is why loading a data: iframe takes more than half a second in this scenario.