RESOLVED FIXED 136847
WTR and DRT didReceiveAuthenticationChallengeInFrame should print messages consistently
https://bugs.webkit.org/show_bug.cgi?id=136847
Summary WTR and DRT didReceiveAuthenticationChallengeInFrame should print messages co...
youenn fablet
Reported 2014-09-16 01:09:11 PDT
DumpRenderTree is printing the URL triggering an auth challenge in the didReceiveAuthenticationChallengeInFrame callback. WebKitTestRunner is not. This should be made consistent. Once consistent, some WK2 specific test expectations could be removed.
Attachments
Patch (31.32 KB, patch)
2014-09-19 02:02 PDT, youenn fablet
no flags
Alexey Proskuryakov
Comment 1 2014-09-16 11:51:59 PDT
I don't think that this can be done. WebKit1 and WebKit2 have different APIs, and we need to test both. WebKit2 does not have the URL in authentication challenge at all.
youenn fablet
Comment 2 2014-09-16 12:34:41 PDT
(In reply to comment #1) > I don't think that this can be done. WebKit1 and WebKit2 have different APIs, and we need to test both. > > WebKit2 does not have the URL in authentication challenge at all. We would need to add a new API for WK2 to get access to the URL through the auth challenge. Alternatively, we could remove URL printing for WK1.
Alexey Proskuryakov
Comment 3 2014-09-16 13:05:51 PDT
> We would need to add a new API for WK2 to get access to the URL through the auth challenge. It's intentional that WebKit2 does not expose it, because that's not always meaningful. Some servers are authenticated per connection, not per resource (notably NTLM authentication). > Alternatively, we could remove URL printing for WK1. In this case, we won't be testing WebKit1 API, which is not good.
youenn fablet
Comment 4 2014-09-16 13:47:50 PDT
(In reply to comment #3) > > We would need to add a new API for WK2 to get access to the URL through the auth challenge. > > It's intentional that WebKit2 does not expose it, because that's not always meaningful. Some servers are authenticated per connection, not per resource (notably NTLM authentication). > > > Alternatively, we could remove URL printing for WK1. > > In this case, we won't be testing WebKit1 API, which is not good. I guess that for these tests then, WK2 test expectations should be made the norm and WK1 the exception.
Alexey Proskuryakov
Comment 5 2014-09-16 13:56:46 PDT
Yes, this seems reasonable to me.
youenn fablet
Comment 6 2014-09-18 02:32:07 PDT
> > It's intentional that WebKit2 does not expose it, because that's not always meaningful. Some servers are authenticated per connection, not per resource (notably NTLM authentication). An improvement would be for WK2 to log the meaningful information, i.e the protection space host and port IIUC. > I guess that for these tests then, WK2 test expectations should be made the norm and WK1 the exception. If there is no objection, I will prepare a patch that would improve WK2 logging and rationalize test expectations for the impacted tests.
youenn fablet
Comment 7 2014-09-19 02:02:37 PDT
youenn fablet
Comment 8 2014-09-19 02:10:08 PDT
> I guess that for these tests then, WK2 test expectations should be made the norm and WK1 the exception. The patch is factorizing modified EFL/GTK/MAC WK2 expected files in platform/wk2. I did not make WK2 test expectations the norm since it may have an impact on WK1 win port. To empty progressively platform/wk2, a platform/wk1 folder may be created to factorize WK1 mac and win ports.
WebKit Commit Bot
Comment 9 2014-09-19 10:38:26 PDT
Comment on attachment 238362 [details] Patch Clearing flags on attachment: 238362 Committed r173760: <http://trac.webkit.org/changeset/173760>
WebKit Commit Bot
Comment 10 2014-09-19 10:38:29 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.