/upgrade-insecure-requests/gen/sharedworker-module-data * tests are expected timeout
Categories
(Core :: DOM: Security, defect)
Tracking
()
People
(Reporter: jmaher, Unassigned)
References
Details
it appears that all the tests (12 total) in the /upgrade-insecure-requests/gen/sharedworker-module-data* path are failing as timeout. I ran a few locally on my windows10 environment and verified this is true.
in the output (for test: upgrade-insecure-requests/gen/sharedworker-module-data.http-rp/upgrade/fetch.https.html) in the test window I see this:
cross-http-downgrade origin and downgrade redirection from https context. assert_equals: The resource request should be 'allowed'. expected "allowed" but got "blocked"
checkResult/<@https://web-platform.test:8443/upgrade-insecure-requests/generic/test-case.sub.js:13:26
promise callbackcheckResult@https://web-platform.test:8443/upgrade-insecure-requests/generic/test-case.sub.js:10:10
promise callbackrunTest/<@https://web-platform.test:8443/upgrade-insecure-requests/generic/test-case.sub.js:32:10
Test.prototype.step@https://web-platform.test:8443/resources/testharness.js:1958:25
promise_test/tests.promise_tests</<@https://web-platform.test:8443/resources/testharness.js:605:36
promise_test/tests.promise_tests<@https://web-platform.test:8443/resources/testharness.js:604:20
promise callback*promise_test@https://web-platform.test:8443/resources/testharness.js:603:51
runTest@https://web-platform.test:8443/upgrade-insecure-requests/generic/test-case.sub.js:25:17
runTests@https://web-platform.test:8443/upgrade-insecure-requests/generic/test-case.sub.js:38:14
@https://web-platform.test:8443/upgrade-insecure-requests/gen/sharedworker-module-data.http-rp/upgrade/fetch.https.html:108:9
I suspect there is a single root cause causing these tests to fail/timeout. Maybe we need a pref set or to do something different in the test case?
Reporter | ||
Comment 1•5 years ago
|
||
:jgraham, is this an area that you could find a pref or verify the harness is doing the correct thing?
Comment 2•5 years ago
|
||
I don't think there's a harness bug here. I got as far as figuring out that we're loading a sharedworker, and postMessaging it. For the first test that seems to work OK. For the second test we get as far as trying to start the worker and send the postMessage, but afaict never get a response. So I'm not sure if the worker never starts (about:debugging only shows a single shared worker) or if something goes wrong inside the worker.
Reporter | ||
Comment 3•5 years ago
|
||
:ckerschb, if you could add this bug to your list of WPT tests that are timing out and need some attention. I suspect some will be easy to fix and others might be harder.
Comment 4•5 years ago
|
||
Just confirmed with baku and we are not supporting modules within workers, hence we can disable those tests.
Reporter | ||
Comment 5•5 years ago
|
||
will solve this in bug 1631882
Description
•