Issue 876674  has been merged into this issue.

Fails on w3c-test.org with a mixed content check failure. Possibly failing as intended?

Passes locally.

See https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/resources/testharnessreport.js.

        // Some tests intentionally load mixed content in order to test the
        // referrer policy, so WebKitAllowRunningInsecureContent must be set
        // to true or else the load would be blocked.
        const paths = [
            'service-workers/service-worker/fetch-event-referrer-policy.https.html',
            'beacon/headers/header-referrer-no-referrer-when-downgrade.https.html',
            'beacon/headers/header-referrer-strict-origin-when-cross-origin.https.html',
            'beacon/headers/header-referrer-strict-origin.https.html',
            'beacon/headers/header-referrer-unsafe-url.https.html',
        ];

Test passes locally because of this setting.

This showing up as broken on wpt.fyi is still an issue, although I agree it may be a wider issue.

foolip@ - thoughts on how we can make sure that these tests don't fail on wpt.fyi due to mixed content blocking?

Alternatively, maybe we should modify the test to only work where mixed content for beacons is allowed?

mkwst@ - is there a way to feature detect mixed content blocking for certain destinations?

If https://w3c.github.io/webappsec-mixed-content/ defines when mixed content blocking happens, then tests in WPT have to assume that mixed content blocking is enabled. If that means that certain things are untestable, it *should* also mean that those things are unreachable/impossible an implementations.

But maybe this aren't as clear cut in practice?