Bug 158919 - [GTK] HTTP auth layout tests are flaky
Summary: [GTK] HTTP auth layout tests are flaky
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 164471
  Show dependency treegraph
 
Reported: 2016-06-19 17:32 PDT by Michael Catanzaro
Modified: 2017-01-03 01:05 PST (History)
5 users (show)

See Also:


Attachments
Patch (5.51 KB, patch)
2017-01-02 02:17 PST, Carlos Garcia Campos
mcatanzaro: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2016-06-19 17:32:40 PDT
The following layout tests have been flaky since r195493-r195495:

http/tests/loading/basic-auth-resend-wrong-credentials.html
http/tests/loading/basic-credentials-sent-automatically.html

Looks like r195493 ("LayoutTest http/tests/security/xssAuditor/embed-tag-in-path-unterminated.html crashing") is the commit to blame. Updating expectations.


--- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/http/tests/loading/basic-auth-resend-wrong-credentials-expected.txt
+++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/http/tests/loading/basic-auth-resend-wrong-credentials-actual.txt
@@ -2,7 +2,6 @@
 main frame - didCommitLoadForFrame
 frame "<!--framePath //<!--frame0-->-->" - didStartProvisionalLoadForFrame
 main frame - didFinishDocumentLoadForFrame
-127.0.0.1:8000 - didReceiveAuthenticationChallenge - Responding with wrongusername:wrongpassword
 frame "<!--framePath //<!--frame0-->-->" - didCommitLoadForFrame
 frame "<!--framePath //<!--frame0-->-->" - didFinishDocumentLoadForFrame
 frame "<!--framePath //<!--frame1-->-->" - didStartProvisionalLoadForFrame
@@ -21,7 +20,7 @@
 --------
 Frame: '<!--framePath //<!--frame0-->-->'
 --------
-Authenticated as user: wrongusername password: wrongpassword
+Authenticated as user: webkit password: rocks
 
 --------
 Frame: '<!--framePath //<!--frame1-->-->'


--- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/http/tests/loading/basic-credentials-sent-automatically-expected.txt
+++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/http/tests/loading/basic-credentials-sent-automatically-actual.txt
@@ -2,13 +2,11 @@
 main frame - didCommitLoadForFrame
 frame "<!--framePath //<!--frame0-->-->" - didStartProvisionalLoadForFrame
 main frame - didFinishDocumentLoadForFrame
-127.0.0.1:8000 - didReceiveAuthenticationChallenge - Responding with first:first-pw
 frame "<!--framePath //<!--frame0-->-->" - didCommitLoadForFrame
 frame "<!--framePath //<!--frame0-->-->" - didFinishDocumentLoadForFrame
 frame "<!--framePath //<!--frame1-->-->" - didStartProvisionalLoadForFrame
 frame "<!--framePath //<!--frame0-->-->" - didHandleOnloadEventsForFrame
 frame "<!--framePath //<!--frame0-->-->" - didFinishLoadForFrame
-127.0.0.1:8000 - didReceiveAuthenticationChallenge - Responding with second:second-pw
 frame "<!--framePath //<!--frame1-->-->" - didCommitLoadForFrame
 frame "<!--framePath //<!--frame1-->-->" - didFinishDocumentLoadForFrame
 frame "<!--framePath //<!--frame2-->-->" - didStartProvisionalLoadForFrame
@@ -39,19 +37,19 @@
 --------
 Frame: '<!--framePath //<!--frame0-->-->'
 --------
-Authenticated as user: first password: first-pw
+Authenticated as user: webkit password: rocks
 
 --------
 Frame: '<!--framePath //<!--frame1-->-->'
 --------
-Authenticated as user: second password: second-pw
+Authenticated as user: webkit password: rocks
 
 --------
 Frame: '<!--framePath //<!--frame2-->-->'
 --------
-Authenticated as user: second password: second-pw
+Authenticated as user: webkit password: rocks
 
 --------
 Frame: '<!--framePath //<!--frame3-->-->'
 --------
-Authenticated as user: second password: second-pw
+Authenticated as user: webkit password: rocks
Comment 1 Carlos Garcia Campos 2016-11-04 07:49:01 PDT
(In reply to comment #0)
> The following layout tests have been flaky since r195493-r195495:
> 
> http/tests/loading/basic-auth-resend-wrong-credentials.html
> http/tests/loading/basic-credentials-sent-automatically.html
> 
> Looks like r195493 ("LayoutTest
> http/tests/security/xssAuditor/embed-tag-in-path-unterminated.html
> crashing") is the commit to blame. Updating expectations.

That commit, nor the one committed after the rollout change the expectations of the tests failing.

> 
> ---
> /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/
> http/tests/loading/basic-auth-resend-wrong-credentials-expected.txt
> +++
> /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/
> http/tests/loading/basic-auth-resend-wrong-credentials-actual.txt
> @@ -2,7 +2,6 @@
>  main frame - didCommitLoadForFrame
>  frame "<!--framePath //<!--frame0-->-->" - didStartProvisionalLoadForFrame
>  main frame - didFinishDocumentLoadForFrame
> -127.0.0.1:8000 - didReceiveAuthenticationChallenge - Responding with
> wrongusername:wrongpassword
>  frame "<!--framePath //<!--frame0-->-->" - didCommitLoadForFrame
>  frame "<!--framePath //<!--frame0-->-->" - didFinishDocumentLoadForFrame
>  frame "<!--framePath //<!--frame1-->-->" - didStartProvisionalLoadForFrame
> @@ -21,7 +20,7 @@
>  --------
>  Frame: '<!--framePath //<!--frame0-->-->'
>  --------
> -Authenticated as user: wrongusername password: wrongpassword
> +Authenticated as user: webkit password: rocks
>  
>  --------
>  Frame: '<!--framePath //<!--frame1-->-->'
> 
> 
> ---
> /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/
> http/tests/loading/basic-credentials-sent-automatically-expected.txt
> +++
> /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/
> http/tests/loading/basic-credentials-sent-automatically-actual.txt
> @@ -2,13 +2,11 @@
>  main frame - didCommitLoadForFrame
>  frame "<!--framePath //<!--frame0-->-->" - didStartProvisionalLoadForFrame
>  main frame - didFinishDocumentLoadForFrame
> -127.0.0.1:8000 - didReceiveAuthenticationChallenge - Responding with
> first:first-pw
>  frame "<!--framePath //<!--frame0-->-->" - didCommitLoadForFrame
>  frame "<!--framePath //<!--frame0-->-->" - didFinishDocumentLoadForFrame
>  frame "<!--framePath //<!--frame1-->-->" - didStartProvisionalLoadForFrame
>  frame "<!--framePath //<!--frame0-->-->" - didHandleOnloadEventsForFrame
>  frame "<!--framePath //<!--frame0-->-->" - didFinishLoadForFrame
> -127.0.0.1:8000 - didReceiveAuthenticationChallenge - Responding with
> second:second-pw
>  frame "<!--framePath //<!--frame1-->-->" - didCommitLoadForFrame
>  frame "<!--framePath //<!--frame1-->-->" - didFinishDocumentLoadForFrame
>  frame "<!--framePath //<!--frame2-->-->" - didStartProvisionalLoadForFrame
> @@ -39,19 +37,19 @@
>  --------
>  Frame: '<!--framePath //<!--frame0-->-->'
>  --------
> -Authenticated as user: first password: first-pw
> +Authenticated as user: webkit password: rocks
>  
>  --------
>  Frame: '<!--framePath //<!--frame1-->-->'
>  --------
> -Authenticated as user: second password: second-pw
> +Authenticated as user: webkit password: rocks
>  
>  --------
>  Frame: '<!--framePath //<!--frame2-->-->'
>  --------
> -Authenticated as user: second password: second-pw
> +Authenticated as user: webkit password: rocks
>  
>  --------
>  Frame: '<!--framePath //<!--frame3-->-->'
>  --------
> -Authenticated as user: second password: second-pw
> +Authenticated as user: webkit password: rocks
Comment 2 Carlos Garcia Campos 2016-11-06 02:22:56 PST
These tests are flaky because they depend on previous auth tests. This explains why it started to fail after r195493 that doesn't change the expectations of these tests, but adds a test that also uses basic-auth-testing.php. So, if you run http/tests/loading/basic-auth-load-URL-with-consecutive-slashes.html and then http/tests/loading/basic-auth-resend-wrong-credentials.html in the same WTR you can see that the second one fails, because it first tries to use the credentials from the previous test (webkit/rocks). We don't receive the first challenge because libsoup already has credentials cached for that uri, but the load fails and we get a 401 and then the correct credentials are used and the authentication success as expected.
The problem is that WTR calls WKContextClearCachedCredentials() before every test in TestController::resetStateToConsistentValues(), and we remove the credentials from the WebCore storage, but libsoup still has its own cache. This proves that we didn0t really need to always padd credentials to soup in the url (see bug #139358), because libsoup always caches the values and use them when possible. So, the solution here to add libsoup API to clear the cached credentials.
Comment 3 Carlos Garcia Campos 2017-01-02 02:17:14 PST
Created attachment 297885 [details]
Patch
Comment 4 Carlos Garcia Campos 2017-01-03 01:05:25 PST
Committed r210234: <http://trac.webkit.org/changeset/210234>