WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WORKSFORME
161052
[WK2] http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upgrade-insecure-fetch-in-main-frame.html fails
https://bugs.webkit.org/show_bug.cgi?id=161052
Summary
[WK2] http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upg...
Alexey Proskuryakov
Reported
2016-08-22 12:37:20 PDT
http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upgrade-insecure-fetch-in-main-frame.html fails every time on my machine (that has macOS Sierra): @@ -1,2 +1,2 @@ -ALERT: PASS: load was not blocked +ALERT: FAIL: load is not successful This test opens a HTTPS window that loads insecure data via the Fetch API. We should upgrade this request and thereby avoid a mixed content resource load. Not sure why it's not failing on the bots. I just run it like this, no fancy options: run-webkit-tests http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upgrade-insecure-fetch-in-main-frame.html
Attachments
Updating TestExpectations
(2.69 KB, patch)
2016-08-23 04:16 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Brent Fulgham
Comment 1
2016-08-22 12:45:01 PDT
(In reply to
comment #0
)
> http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upgrade- > insecure-fetch-in-main-frame.html fails every time on my machine (that has > macOS Sierra):
Do all the other tests pass? I.e., do you have a working local SSL configuration and so forth? We might need Youenn's help to figure out what might be wrong.
youenn fablet
Comment 2
2016-08-22 12:51:59 PDT
It is working on my setup. I'll try it tomorrow on an updated setup
Brent Fulgham
Comment 3
2016-08-22 12:52:37 PDT
(In reply to
comment #2
)
> It is working on my setup. I'll try it tomorrow on an updated setup
Yes, it works for me as well -- and I'm using Sierra as well.
Alexey Proskuryakov
Comment 4
2016-08-22 12:56:44 PDT
Yes, all other tests pass.
youenn fablet
Comment 5
2016-08-22 13:05:28 PDT
Can the apache log provide some useful information?
Alexey Proskuryakov
Comment 6
2016-08-22 13:54:17 PDT
Debugged this down to an actual HTTPS connection failure. Will follow up in e-mail.
Radar WebKit Bug Importer
Comment 7
2016-08-22 14:16:41 PDT
<
rdar://problem/27954577
>
Alexey Proskuryakov
Comment 8
2016-08-22 15:14:25 PDT
What changed here is that Fetch got enabled in
r204705
. These tests should have been disabled in the past, but they were not. The actual issue will be tracked in Radar.
youenn fablet
Comment 9
2016-08-23 04:09:53 PDT
(In reply to
comment #8
)
> What changed here is that Fetch got enabled in
r204705
. These tests should > have been disabled in the past, but they were not.
This test works fine in WK1. It does not work as expected on WK2 as the test runtime flag (on) was different from the web view runtime flag (off until
r204705
). When creating the new frame, fetch runtime flag was set to off and fetch API was disappearing. I am now hitting the same issue as ap. I will add Fail to mac-wk2 TestExpectations, similarly to http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upgrade-insecure-fetch-in-worker.html I will wait some more time to remove the 'Timeout' expectation for those tests.
youenn fablet
Comment 10
2016-08-23 04:10:21 PDT
Reopened (see above comment)
youenn fablet
Comment 11
2016-08-23 04:16:39 PDT
Created
attachment 286697
[details]
Updating TestExpectations
WebKit Commit Bot
Comment 12
2016-08-23 05:15:48 PDT
Comment on
attachment 286697
[details]
Updating TestExpectations Clearing flags on attachment: 286697 Committed
r204817
: <
http://trac.webkit.org/changeset/204817
>
WebKit Commit Bot
Comment 13
2016-08-23 05:15:52 PDT
All reviewed patches have been landed. Closing bug.
youenn fablet
Comment 14
2016-08-23 06:18:40 PDT
Reopened to follow on the bug.
Alexey Proskuryakov
Comment 15
2016-08-23 10:07:58 PDT
Comment on
attachment 286697
[details]
Updating TestExpectations View in context:
https://bugs.webkit.org/attachment.cgi?id=286697&action=review
> LayoutTests/platform/mac-wk2/TestExpectations:381 >
webkit.org/b/160445
http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upgrade-insecure-fetch-in-worker.html [ Failure Timeout ] > +
webkit.org/b/160445
http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upgrade-insecure-fetch-in-main-frame.html [ Failure Timeout ]
Why are we allowing for Timeout here? Also, shouldn't the expectation be Sierra only?
youenn fablet
Comment 16
2016-08-23 10:24:18 PDT
(In reply to
comment #15
)
> Comment on
attachment 286697
[details]
> Updating TestExpectations > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=286697&action=review
> > > LayoutTests/platform/mac-wk2/TestExpectations:381 > >
webkit.org/b/160445
http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upgrade-insecure-fetch-in-worker.html [ Failure Timeout ] > > +
webkit.org/b/160445
http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/upgrade-insecure-fetch-in-main-frame.html [ Failure Timeout ] > > Why are we allowing for Timeout here?
Test was timing out previously due to fetch runtime flag issue. I am just leaving the Timeout to ensure there is no issue here. The bots seem to like that, I'll update it tomorrow if there is no issue.
> Also, shouldn't the expectation be Sierra only?
Probably, I'll fix that when removing the Timeout expectation.
Ben Schwartz
Comment 17
2024-06-20 11:24:56 PDT
This no longer seems to be occurring. Please file a new bug if issues persist.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug