Bug 159724 – LayoutTest imported/w3c/web-platform-tests/XMLHttpRequest/send-redirect-post-upload.htm asserts in WebKitLegacy

• Status: RESOLVED
• Resolution: WONTFIX
• Component: New Bugs

[Ryan Haddad]

LayoutTest imported/w3c/web-platform-tests/XMLHttpRequest/send-redirect-post-upload.htm failing

Test was imported in http://trac.webkit.org/changeset/203164 with a Pass Crash expectation, but it appears to be failing on Mac and iOS-simulator.

https://build.webkit.org/results/Apple%20El%20Capitan%20Release%20WK2%20(Tests)/r203164%20(7598)/results.html

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=imported%2Fw3c%2Fweb-platform-tests%2FXMLHttpRequest%2Fsend-redirect-post-upload.htm

--- /Volumes/Data/slave/elcapitan-release-tests-wk2/build/layout-test-results/imported/w3c/web-platform-tests/XMLHttpRequest/send-redirect-post-upload-expected.txt
+++ /Volumes/Data/slave/elcapitan-release-tests-wk2/build/layout-test-results/imported/w3c/web-platform-tests/XMLHttpRequest/send-redirect-post-upload-actual.txt
@@ -2,5 +2,5 @@
 PASS XMLHttpRequest: The send() method: POSTing to URL that redirects (301) 
 PASS XMLHttpRequest: The send() method: POSTing to URL that redirects (302) 
 PASS XMLHttpRequest: The send() method: POSTing to URL that redirects (303) 
-PASS XMLHttpRequest: The send() method: POSTing to URL that redirects (307) 
+FAIL XMLHttpRequest: The send() method: POSTing to URL that redirects (307) assert_equals: X-Request-Content-Length expected "11988" but got "0"

[Ryan Haddad]

Specifically, it is failing on Release WK2.

[youenn fablet]

I am out for 30 minutes. I'll fix that if it is not done so. Sorry for the inconvenience

[Ryan Haddad]

(In reply to comment #2)
> I am out for 30 minutes. I'll fix that if it is not done so. Sorry for the
> inconvenience

Thank you! In the meantime, I have marked the test as failing on Mac and ios-sim Release WK2 in <http://trac.webkit.org/projects/webkit/changeset/203166>

[youenn fablet]

(In reply to comment #3)
> (In reply to comment #2)
> > I am out for 30 minutes. I'll fix that if it is not done so. Sorry for the
> > inconvenience
> 
> Thank you! In the meantime, I have marked the test as failing on Mac and
> ios-sim Release WK2 in
> <http://trac.webkit.org/projects/webkit/changeset/203166>

Thanks, I'll try to fix it tomorrow then.

[youenn fablet]

The test seems flaky on passing WK1 bots.
On Mac/WK2, it is as if the body is not preserved during the 307 redirection.
This ends up in an assertion being raised for debug builds and a request content-length being equal to 0.

[youenn fablet]

(In reply to comment #5)
> The test seems flaky on passing WK1 bots.

On other browsers and other ports, the test seems fragile also.
The counting of events seems to be easily broken by browsers.

[youenn fablet]

Created attachment 284003 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 284003 [details]
Patch

Clearing flags on attachment: 284003

Committed r203405: <http://trac.webkit.org/changeset/203405>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[youenn fablet]

Reopening to continue tracking the actual bug

[youenn fablet]

I saw https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK2%20(Tests)/r203411%20(6684)/com.apple.WebKit.Networking-crash-log.txt which seems to hit the same assertion.
Maybe we should skip this test altogether.

[Alexey Proskuryakov]

0   com.apple.JavaScriptCore      	0x000000010b906417 WTFCrash + 39 (Assertions.cpp:323)
1   com.apple.WebCore             	0x000000010fbe06a5 WebCore::ResourceRequest::doUpdateResourceHTTPBody() + 325 (ResourceRequestCocoa.mm:115)
2   com.apple.WebCore             	0x000000010fbddc0d WebCore::ResourceRequestBase::updateResourceRequest(WebCore::HTTPBodyUpdatePolicy) const + 237 (ResourceRequestBase.cpp:586)
3   com.apple.WebCore             	0x000000010fbde6de WebCore::ResourceRequestBase::httpBody() const + 30 (ResourceRequestBase.cpp:397)
4   com.apple.WebCore             	0x000000010fbdf8ef WebCore::ResourceRequest::updateFromDelegatePreservingOldProperties(WebCore::ResourceRequest const&) + 47 (ResourceRequestCFNet.cpp:331)
5   com.apple.WebKit              	0x0000000106c60e81 WebKit::NetworkLoad::continueWillSendRequest(WebCore::ResourceRequest&&) + 97 (NetworkLoad.cpp:118)
6   com.apple.WebKit              	0x0000000106cab934 WebKit::NetworkResourceLoader::continueWillSendRequest(WebCore::ResourceRequest&&) + 244 (NetworkResourceLoader.cpp:474)
7   com.apple.WebKit              	0x0000000106cb64ef void IPC::callMemberFunctionImpl<WebKit::NetworkResourceLoader, void (WebKit::NetworkResourceLoader::*)(WebCore::ResourceRequest&&), std::__1::tuple<WebCore::ResourceRequest>, 0ul>(WebKit::NetworkResourceLoader*, void (WebKit::NetworkResourceLoader::*)(WebCore::ResourceRequest&&), std::__1::tuple<WebCore::ResourceRequest>&&, std::__1::integer_sequence<unsigned long, 0ul>) + 159 (HandleMessage.h:17)

[Alexey Proskuryakov]

This test asserts 100% of time in debug, so it should indeed be skipped until a fix is found. Running CrashReporter is costly, and can destabilize other tests.

It is a flaky failure in release.

[youenn fablet]

Created attachment 285303 [details]
Patch for landing

[youenn fablet]

(In reply to comment #14)
> Created attachment 285303 [details]
> Patch for landing

Skipping for Debug Mac bots.
Marking as flaky for all Release bots.

[WebKit Commit Bot]

Comment on attachment 285303 [details]
Patch for landing

Clearing flags on attachment: 285303

Committed r204116: <http://trac.webkit.org/changeset/204116>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[youenn fablet]

Reopening to continue the investigation

[Ms2ger (he/him; ⌚ UTC+1/+2)]

Filed an upstream bug: https://github.com/w3c/web-platform-tests/issues/8191

Note that the current flakiness is between

PASS XMLHttpRequest: The send() method: POSTing to URL that redirects (307)
FAIL XMLHttpRequest: The send() method: POSTing to URL that redirects (307) assert_array_equals: events firing in expected order and states lengths differ, expected 9 got 10

rather than any failures in earlier comments.

[Alex Christensen]

Created attachment 366219 [details]
Patch

[Alex Christensen]

*** Bug 196274 has been marked as a duplicate of this bug. ***

[Alex Christensen]

Created attachment 366220 [details]
Patch

[EWS Watchlist]

Comment on attachment 366220 [details]
Patch

Attachment 366220 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/11696202

New failing tests:
http/tests/local/fileapi/send-sliced-dragged-file.html

[EWS Watchlist]

Created attachment 366224 [details]
Archive of layout-test-results from ews100 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 366220 [details]
Patch

Attachment 366220 [details] did not pass mac-debug-ews (mac):
Output: https://webkit-queues.webkit.org/results/11696440

New failing tests:
http/tests/local/fileapi/send-sliced-dragged-file.html

[EWS Watchlist]

Created attachment 366229 [details]
Archive of layout-test-results from ews115 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[Alex Christensen]

Created attachment 366239 [details]
Patch

[Alex Christensen]

Comment on attachment 366239 [details]
Patch

Brady said we should not do this improvement to WebKitLegacy, especially since it has a known regression that needs working around.  I agree.

[Alex Christensen]

http://trac.webkit.org/r243655 updated the TestExpectations.

[Alex Christensen]

*** Bug 184365 has been marked as a duplicate of this bug. ***