Closed Bug 1632119 Opened 5 years ago Closed 5 years ago

/upgrade-insecure-requests/gen/sharedworker-module-data * tests are expected timeout

Categories

(Core :: DOM: Security, defect)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1631882

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 callback
runTest/<@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?

:jgraham, is this an area that you could find a pref or verify the harness is doing the correct thing?

Flags: needinfo?(james)

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.

Flags: needinfo?(james)

: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.

Flags: needinfo?(ckerschb)

Just confirmed with baku and we are not supporting modules within workers, hence we can disable those tests.

Flags: needinfo?(ckerschb)

will solve this in bug 1631882

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.