Bug 181008 - Layout Test http/tests/images/image-supports-video.html is flaky
Summary: Layout Test http/tests/images/image-supports-video.html is flaky
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jer Noble
URL:
Keywords: InRadar
: 181862 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-12-19 16:11 PST by Matt Lewis
Modified: 2018-01-19 10:10 PST (History)
6 users (show)

See Also:


Attachments
Patch (2.15 KB, patch)
2018-01-17 22:42 PST, Jer Noble
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Lewis 2017-12-19 16:11:08 PST
The following layout test is flaky on macOS WK!

http/tests/images/image-supports-video.html

Probable cause:

Test was flaky from the initial commit in https://trac.webkit.org/changeset/225472/webkit

Flakiness Dashboard:

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Ftests%2Fimages%2Fimage-supports-video.html


https://build.webkit.org/results/Apple%20Sierra%20Debug%20WK1%20(Tests)/r226129%20(5383)/results.html
https://build.webkit.org/builders/Apple%20Sierra%20Debug%20WK1%20(Tests)/builds/5383

diff:

--- /Volumes/Data/slave/sierra-debug-tests-wk1/build/layout-test-results/http/tests/images/image-supports-video-expected.txt
+++ /Volumes/Data/slave/sierra-debug-tests-wk1/build/layout-test-results/http/tests/images/image-supports-video-actual.txt
@@ -1,2 +1,2 @@
   
-PASS: video source selected.
+FAIL: <img> threw error.
Comment 1 Radar WebKit Bug Importer 2017-12-19 16:11:29 PST
<rdar://problem/36143943>
Comment 2 Matt Lewis 2017-12-19 16:59:52 PST
Marked as flaky on macOS WK1: https://trac.webkit.org/changeset/226159/webkit
Comment 3 Jer Noble 2017-12-20 17:46:42 PST
From the access_log.txt on the failing test, I see a request for the initial image URL (meaning the test passed), but not for the redirected URL.ng

e.g., on a passing run:

127.0.0.1 - - [20/Dec/2017:12:17:29 -0800] "GET /resources/redirect-to-video-if-accepted.php?video=test.mp4 HTTP/1.1" 301 - 1356
127.0.0.1 - - [20/Dec/2017:12:17:29 -0800] "GET /resources/test.mp4 HTTP/1.1" 200 192844 1862

and on a failing run:

127.0.0.1 - - [09/Dec/2017:13:51:01 -0800] "GET /resources/redirect-to-video-if-accepted.php?video=test.mp4 HTTP/1.1" 301 - 1163

(with no matching request for "test.mp4".)

Could we be hitting a weird memory cache corner case?
Comment 4 Jer Noble 2017-12-20 18:10:33 PST
This may be just another instance of bug #77538, which is worked around by adding a cache-control error.
Comment 5 Jer Noble 2018-01-17 22:42:10 PST
Created attachment 331599 [details]
Patch
Comment 6 WebKit Commit Bot 2018-01-18 00:33:19 PST
Comment on attachment 331599 [details]
Patch

Clearing flags on attachment: 331599

Committed r227137: <https://trac.webkit.org/changeset/227137>
Comment 7 WebKit Commit Bot 2018-01-18 00:33:20 PST
All reviewed patches have been landed.  Closing bug.
Comment 8 Ryan Haddad 2018-01-19 09:49:42 PST
*** Bug 181862 has been marked as a duplicate of this bug. ***
Comment 9 Ryan Haddad 2018-01-19 09:50:49 PST
This test is still flaky after https://trac.webkit.org/changeset/227137
Comment 10 Jer Noble 2018-01-19 10:10:56 PST
(In reply to Ryan Haddad from comment #9)
> This test is still flaky after https://trac.webkit.org/changeset/227137

Crud.