RESOLVED FIXED 73913
[WK2] New tests introduced in r100895 fail
https://bugs.webkit.org/show_bug.cgi?id=73913
Summary [WK2] New tests introduced in r100895 fail
Csaba Osztrogonác
Reported 2011-12-06 05:37:40 PST
Same fails on SL-WK2 and on Qt-WK2: FAIL: Timed out waiting for notifyDone to be called http/tests/security/referrer-policy-https-always.html: http/tests/security/referrer-policy-https-origin.html http/tests/security/referrer-policy-redirect.html http/tests/security/referrer-policy-https-never.html http/tests/security/referrer-policy-https-default.html
Attachments
Patch (1.67 KB, patch)
2013-02-06 04:37 PST, Marja Hölttä
no flags
Patch (1.74 KB, patch)
2013-02-06 04:44 PST, Marja Hölttä
no flags
jochen
Comment 1 2011-12-06 05:41:31 PST
When did those tests start to fail?
Csaba Osztrogonác
Comment 2 2011-12-06 05:45:07 PST
(In reply to comment #1) > When did those tests start to fail? Since they are introduced: r100895.
Csaba Osztrogonác
Comment 3 2011-12-06 05:57:15 PST
I skipped them to make buildbots a little bit happier: http://trac.webkit.org/changeset/102127
jochen
Comment 4 2011-12-06 05:57:57 PST
ok, I will look into why this fails
jochen
Comment 5 2011-12-06 08:27:45 PST
The tests work locally, although they're all pretty slow on WK2. The difference between these and the remaining tests in that CL is that they redirect through https Could this cause the slowness?
jochen
Comment 6 2011-12-12 07:49:11 PST
Actually, it's not slowness, but WebKitTestRunner doesn't load resources over https for whatever reason. Other tests requiring ssl (like all in http/tests/ssl/) are disabled as well
Alexey Proskuryakov
Comment 7 2011-12-12 08:07:03 PST
In Mac case at least, that could be because of a self signed certificate. DRT has code to silence those, while WTR does not. [NSURLRequest setAllowsAnyHTTPSCertificate:YES forHost:@"localhost"]; [NSURLRequest setAllowsAnyHTTPSCertificate:YES forHost:@"127.0.0.1"];
jochen
Comment 8 2011-12-12 08:28:56 PST
(In reply to comment #7) > In Mac case at least, that could be because of a self signed certificate. DRT has code to silence those, while WTR does not. > > [NSURLRequest setAllowsAnyHTTPSCertificate:YES forHost:@"localhost"]; > [NSURLRequest setAllowsAnyHTTPSCertificate:YES forHost:@"127.0.0.1"]; that might be very well true (I've tried to get the tests work on a Mac). I guess that code needs to be run in the same process that does the actual loading. I've put these lines in InjectedBundle/mac/LayoutTestControllerMac::platformInitialize, but the tests still don't work Given that I don't know much about the WebKitTestRunner, this might be the wrong place... I'll continue to look into this
Roger Fong
Comment 9 2012-08-30 17:28:58 PDT
DRT has similar issues. I''m testing on Windows. Adding to skip list as well.
Alexey Proskuryakov
Comment 10 2013-02-04 08:31:39 PST
> [NSURLRequest setAllowsAnyHTTPSCertificate:YES forHost:@"localhost"]; > [NSURLRequest setAllowsAnyHTTPSCertificate:YES forHost:@"127.0.0.1"]; WebKitTestRunner now does this in InjectedBundleMac.mm. Are the tests still failing?
Marja Hölttä
Comment 11 2013-02-06 04:35:40 PST
These seem to be passing now afaics. I'll attach a patch to unskip them.
Marja Hölttä
Comment 12 2013-02-06 04:37:06 PST
jochen
Comment 13 2013-02-06 04:39:52 PST
Comment on attachment 186826 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=186826&action=review r=me > LayoutTests/ChangeLog:3 > + Unskipping tests which no longer fail. could you add some more details: something like unskipping referrer policy tests now that WTR supports https tests
Marja Hölttä
Comment 14 2013-02-06 04:44:26 PST
Marja Hölttä
Comment 15 2013-02-06 04:46:02 PST
Comment on attachment 186828 [details] Patch (Added more information in the ChangeLog.)
WebKit Review Bot
Comment 16 2013-02-06 05:38:58 PST
Comment on attachment 186828 [details] Patch Clearing flags on attachment: 186828 Committed r141994: <http://trac.webkit.org/changeset/141994>
WebKit Review Bot
Comment 17 2013-02-06 05:39:03 PST
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.