Bug 242270 - REGRESSION (March 2022): [ iOS Debug ] fast/encoding/char-after-fast-path-ascii-decoding.html is a flaky failure
Summary: REGRESSION (March 2022): [ iOS Debug ] fast/encoding/char-after-fast-path-asc...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: EasyFix, InRadar
Depends on:
Blocks:
 
Reported: 2022-07-01 15:01 PDT by Karl Rackler
Modified: 2022-07-04 11:25 PDT (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.