Short version: When I run a mochitest with `--use-http3-server`, the test fails if it relies on anything other than `https://mochi.test:8888`, `https://example.com` or `https://example.net`. It seems that these are listed in the initial patch for bug 1809843, at [build/pgo/certs/mochitest-cert.certspec](https://searchfox.org/mozilla-central/rev/11dbac7f64f509b78037465cbb4427ed71f8b565/build/pgo/certs/mochitest-cert.certspec#5). These few server names are not enough. There are many more https:-locations in [build/pgo/server-locations.txt](https://searchfox.org/mozilla-central/rev/11dbac7f64f509b78037465cbb4427ed71f8b565/build/pgo/server-locations.txt) that are relied upon by mochitests. Expanding the list of domains would allow the removal of many `skip-if = http3` from test manifests (and also avoid backouts of patches due to http3 test failures, which is why I started investigating this). ### Detailed analysis I observed a backout of my patch at https://bugzilla.mozilla.org/show_bug.cgi?id=1825824#c5 because the new test fails on M-http3. The test gets stuck at the part where it tries to load https://example.net - https://hg.mozilla.org/integration/autoland/rev/013b29254435#l3.100 I get the following log when I run the test on a debug build, with `./mach test toolkit/components/extensions/test/mochitest/test_ext_dnr_other_extensions.html --tag=remote-webextensions --headless --compare-preferences --log-mach-verbose --use-http3-server`: > 0:21.87 INFO add_task | Entering tabs_create_can_be_redirected_by_other_dnr_extension 0:21.88 INFO Extension loaded 0:22.04 INFO Extension loaded 0:22.22 INFO Waiting for navigation done, starting from https://example.net/?dnr_redir_me_pls **0:22.24 GECKO(59877) [WARN neqo_crypto::agent] [Agent 0x10d479490] error: NssError { name: "SSL_ERROR_HANDSHAKE_FAILED", code: -12116, desc: "SSL handshake has already failed. No more operations possible." }** Note the error in the end... After some trial and error with other tests, it seems apparent that the https3 test server only supports `https://mochi.test:8888`, `https://example.com` and `https://example.net`. I found these additional URLs by running `./mach test toolkit/components/extensions/test/mochitest/test_ext_exclude_include_globs.html --tag=remote-webextensions --headless --compare-preferences --log-mach-verbose --use-https3-server`, because that fails ultimately, but not before showing some successful loads: > 0:13.93 TEST_START: toolkit/components/extensions/test/mochitest/test_ext_exclude_include_globs.html 0:17.00 INFO add_task | Entering test_contentscript 0:17.01 INFO Extension loaded 0:17.05 INFO extension loaded 0:17.10 GECKO(60228) Console message: [JavaScript Warning: "Storage access automatically granted for origin “https://example.org” on “https://mochi.test:8888”."] **0:18.13 GECKO(60228) Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "https://example.org/" line: 0}]** 0:18.30 PASS undefined assertion name 0:18.43 GECKO(60228) Console message: [JavaScript Warning: "Storage access automatically granted for origin “https://test1.example.org” on “https://mochi.test:8888”."] > *test gets stuck here, i.e. test1.example.org did not load* The log above shows that https://example.org was successfully loaded. And indeed, when I change example.net to example.org in the failing test from bug 1825824, the test passes with https3. The "working" domains are listed in the patch from bug 1809843 at https://hg.mozilla.org/mozilla-central/rev/8699a91328fc380d567ce028e28014ff1965d992#l8.3. That seems not a coincidence...
Bug 1827526 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Short version: When I run a mochitest with `--use-http3-server`, the test fails if it relies on anything other than `https://mochi.test:8888`, `https://example.com` or `https://example.org`. It seems that these are listed in the initial patch for bug 1809843, at [build/pgo/certs/mochitest-cert.certspec](https://searchfox.org/mozilla-central/rev/11dbac7f64f509b78037465cbb4427ed71f8b565/build/pgo/certs/mochitest-cert.certspec#5). These few server names are not enough. There are many more https:-locations in [build/pgo/server-locations.txt](https://searchfox.org/mozilla-central/rev/11dbac7f64f509b78037465cbb4427ed71f8b565/build/pgo/server-locations.txt) that are relied upon by mochitests. Expanding the list of domains would allow the removal of many `skip-if = http3` from test manifests (and also avoid backouts of patches due to http3 test failures, which is why I started investigating this). ### Detailed analysis I observed a backout of my patch at https://bugzilla.mozilla.org/show_bug.cgi?id=1825824#c5 because the new test fails on M-http3. The test gets stuck at the part where it tries to load https://example.net - https://hg.mozilla.org/integration/autoland/rev/013b29254435#l3.100 I get the following log when I run the test on a debug build, with `./mach test toolkit/components/extensions/test/mochitest/test_ext_dnr_other_extensions.html --tag=remote-webextensions --headless --compare-preferences --log-mach-verbose --use-http3-server`: > 0:21.87 INFO add_task | Entering tabs_create_can_be_redirected_by_other_dnr_extension 0:21.88 INFO Extension loaded 0:22.04 INFO Extension loaded 0:22.22 INFO Waiting for navigation done, starting from https://example.net/?dnr_redir_me_pls **0:22.24 GECKO(59877) [WARN neqo_crypto::agent] [Agent 0x10d479490] error: NssError { name: "SSL_ERROR_HANDSHAKE_FAILED", code: -12116, desc: "SSL handshake has already failed. No more operations possible." }** Note the error in the end... After some trial and error with other tests, it seems apparent that the https3 test server only supports `https://mochi.test:8888`, `https://example.com` and `https://example.org`. I found these additional URLs by running `./mach test toolkit/components/extensions/test/mochitest/test_ext_exclude_include_globs.html --tag=remote-webextensions --headless --compare-preferences --log-mach-verbose --use-https3-server`, because that fails ultimately, but not before showing some successful loads: > 0:13.93 TEST_START: toolkit/components/extensions/test/mochitest/test_ext_exclude_include_globs.html 0:17.00 INFO add_task | Entering test_contentscript 0:17.01 INFO Extension loaded 0:17.05 INFO extension loaded 0:17.10 GECKO(60228) Console message: [JavaScript Warning: "Storage access automatically granted for origin “https://example.org” on “https://mochi.test:8888”."] **0:18.13 GECKO(60228) Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "https://example.org/" line: 0}]** 0:18.30 PASS undefined assertion name 0:18.43 GECKO(60228) Console message: [JavaScript Warning: "Storage access automatically granted for origin “https://test1.example.org” on “https://mochi.test:8888”."] > *test gets stuck here, i.e. test1.example.org did not load* The log above shows that https://example.org was successfully loaded. And indeed, when I change example.net to example.org in the failing test from bug 1825824, the test passes with https3. The "working" domains are listed in the patch from bug 1809843 at https://hg.mozilla.org/mozilla-central/rev/8699a91328fc380d567ce028e28014ff1965d992#l8.3. That seems not a coincidence...