Bug 81627 – [WK2] HTTP authentication regression tests fail

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Tim Horton]

http/tests/xmlhttprequest/basic-auth-default.html
http/tests/xmlhttprequest/basic-auth.html
http/tests/xmlhttprequest/re-login-async.html
http/tests/xmlhttprequest/workers/abort-exception-assert.html

See: http://build.webkit.org/results/Lion%20Intel%20Debug%20%28WebKit2%20Tests%29/r111269%20%285060%29/results.html

100% reproducible locally

Skipping for now.

[Tim Horton]

Skipped in http://trac.webkit.org/changeset/111346

[Radar WebKit Bug Importer]

<rdar://problem/11079296>

[Alexey Proskuryakov]

1. WebKitTestRunner doesn't implement PageLoaderClient.canAuthenticateAgainstProtectionSpaceInFrame. If we add it, and make it return true, tests will pass.

2. In WebKit1, the unimplemented delegate defaults to true for all "old" authentication schemes, and only defaults to false for new ones. This was presumably necessary to not break clients that can't show UI for client certificates.

In WebKit2, both C and Objective-C APIs default to false unconditionally. This may be not the most reasonable behavior.

3. In this particular case - loading a resource with explicitly provided credentials - we probably shouldn't ask the client whether it supports password based authentication at all unless the credentials turn out to be incorrect. The fix for this would be in ResourceHandle in WebCore.

So, fixing the tests by implementing the client call is trivial, but we should think about how the API should work.

[Alexey Proskuryakov]

> 3. In this particular case - loading a resource with explicitly provided credentials - we probably shouldn't ask the client whether it supports password based authentication at all unless the credentials turn out to be incorrect. The fix for this would be in ResourceHandle in WebCore.

Filed bug 131348 for this.

[Alexey Proskuryakov]

> http/tests/xmlhttprequest/workers/abort-exception-assert.html

This test appears unrelated to the previous three, but it currently passes anyway.

[Alexey Proskuryakov]

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

[Alexey Proskuryakov]

Created attachment 228815 [details]
proposed fix

[Build Bot]

Comment on attachment 228815 [details]
proposed fix

Attachment 228815 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/5659814722011136

New failing tests:
platform/mac/fast/scrolling/scroll-iframe-latched-mainframe.html
platform/mac/fast/scrolling/scroll-div-latched-mainframe.html
http/tests/misc/dns-prefetch-control.html
platform/mac/fast/scrolling/scroll-select-latched-mainframe.html

[Build Bot]

Created attachment 228826 [details]
Archive of layout-test-results from webkit-ews-10 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-10  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Build Bot]

Comment on attachment 228815 [details]
proposed fix

Attachment 228815 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/6504239652143104

New failing tests:
platform/mac/fast/scrolling/scroll-iframe-latched-mainframe.html
platform/mac/fast/scrolling/scroll-div-latched-mainframe.html
http/tests/misc/dns-prefetch-control.html
platform/mac/fast/scrolling/scroll-select-latched-mainframe.html

[Build Bot]

Created attachment 228827 [details]
Archive of layout-test-results from webkit-ews-16 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-16  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Alexey Proskuryakov]

> http/tests/misc/dns-prefetch-control.html

This complaint is correct, this test probably started seeing bug 131349. I'll check.

E-mailed Brent about missing results in latching tests.

[Alexey Proskuryakov]

(In reply to comment #12)
> > http/tests/misc/dns-prefetch-control.html
> 
> This complaint is correct, this test probably started seeing bug 131349. I'll check.

Turns out that this was different. We were getting server trust challenge on this test.

Fixing by only returning true for password based authentication schemes.

[Alexey Proskuryakov]

Created attachment 228942 [details]
patch for landing

[WebKit Commit Bot]

Comment on attachment 228942 [details]
patch for landing

Clearing flags on attachment: 228942

Committed r167007: <http://trac.webkit.org/changeset/167007>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.