test: allow happy-dom suite to pass

Author: rexxars

.github/workflows/test.yml

@@ -106,11 +106,25 @@ jobs:
       - name: Run tests
         run: npm run test:bun
 
+  testHappyDom:
+    name: 'Test: happy-dom'
+    timeout-minutes: 15
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/setup-node@v7
+        with:
+          node-version: 24
+      - name: Install dependencies
+        run: npm ci
+      - name: Run tests
+        run: npm run test:happy-dom
+
   # Known-failing environments, reported but never gating.
   #
-  # happy-dom reports the test server's requests as cross-origin and blocks them. workerd's
-  # remaining failures all trace to cloudflare/workerd#6022, where its `EventTarget` dispatches
-  # `on<type>` handler properties itself and so fires our `on*` handlers twice.
+  # Seven of workerd's eight failures trace to cloudflare/workerd#6022, where its `EventTarget`
+  # dispatches `on<type>` handler properties itself and so fires our `on*` handlers twice. The
+  # eighth is a message-wording difference only, see CONTRIBUTING.md.
   #
   # `continue-on-error` is deliberately on the *step* rather than the job. At job level it keeps
   # the overall run green but the job still reports a check run with a `failure` conclusion, which
@@ -124,7 +138,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        suite: ['happy-dom', 'workerd']
+        suite: ['workerd']
     steps:
       - uses: actions/checkout@v7
       - uses: actions/setup-node@v7

CONTRIBUTING.md

@@ -35,7 +35,9 @@ The suite in `test/client.test.ts` runs against a real HTTP server in every supp
 
 The browser tests need Playwright's browsers installed once, with `npx playwright install chromium firefox webkit`.
 
-The happy-dom and workerd suites are expected to fail today and do not gate CI. happy-dom reports the test server's requests as cross-origin and blocks them. workerd's remaining failures all come from [cloudflare/workerd#6022](https://github.com/cloudflare/workerd/issues/6022): its `EventTarget` dispatches `on<type>` handler properties itself, on top of the `addEventListener` call our `on*` setters make, so those handlers fire twice, assigning `null` only removes one registration, and they fire ahead of listeners registered before them.
+The workerd suite is expected to fail today and does not gate CI. Seven of its eight failures come from [cloudflare/workerd#6022](https://github.com/cloudflare/workerd/issues/6022): its `EventTarget` dispatches `on<type>` handler properties itself, on top of the `addEventListener` call our `on*` setters make, so those handlers fire twice, assigning `null` only removes one registration, and they fire ahead of listeners registered before them. The eighth is only a wording difference - workerd reports a refused connection as `Network connection lost.`, which the per-runtime message pattern in the extended-properties test does not cover.
+
+happy-dom gates CI, with one exception: it does not strip `Authorization` when a request is redirected to a different origin, as [the fetch spec requires](https://fetch.spec.whatwg.org/#http-redirect-fetch), so the four cross-origin redirect tests are asserted as known failures there rather than skipped. They turn red - prompting removal of the workaround - as soon as happy-dom fixes it.
 
 The browser suite is the one place where the endpoints are not served by a standalone server. Vitest serves the test page from its own Vite server, so the endpoints are mounted onto that same server (`test/helpers/ssePlugin.ts`) to keep the page and the endpoints same-origin. Serving them separately would make every request cross-origin and silently change what the CORS, cookie and redirect tests actually assert.
 

test/client.test.ts

@@ -15,12 +15,22 @@ import {
   request,
   serverOrigin,
   serverUrl,
+  suite,
 } from './helpers/env.ts'
 import {unicodeLines} from './helpers/fixtures.ts'
 
 /** Only meaningful where CORS, cookies and `withCredentials` are actually enforced. */
 const browserTest = test.runIf(hasBrowserSemantics)
 
+/**
+ * happy-dom copies the full header list onto a redirected request and only ever deletes the
+ * cookie headers, so `Authorization` survives a redirect to a different origin - which the fetch
+ * spec requires it not to (https://fetch.spec.whatwg.org/#http-redirect-fetch, step 13). Asserted
+ * as a known failure rather than skipped, so that this turns red - and the workaround gets
+ * removed - the moment happy-dom starts stripping the header.
+ */
+const xOriginRedirectTest = suite === 'happy-dom' ? test.fails : test
+
 test('can connect, receive message, manually disconnect', async () => {
   const onMessage = getCallCounter({name: 'onMessage'})
   const es = new OurEventSource(new URL(`${serverUrl}/`))
@@ -532,7 +542,7 @@ test('can request cross-origin', async () => {
 
 // Cross-origin redirect tests
 ;[301, 302, 307, 308].forEach((status) => {
-  test(`redirects: handles ${status} to different origin`, async () => {
+  xOriginRedirectTest(`redirects: handles ${status} to different origin`, async () => {
     const id = Math.random().toString(36).slice(2)
     const onMessage = getCallCounter({name: 'onMessage'})
     const onOpen = getCallCounter<Event>({name: 'onOpen'})
@@ -730,7 +740,7 @@ test('[NON-SPEC] message event contains extended properties (failed connection)'
     timeStamp: expect.any(Number),
     // Node, Deno, Bun, Chromium, Webkit, Firefox _ALL_ have different messages 😅
     message: expect.stringMatching(
-      /fetch failed|failed to fetch|load failed|attempting to fetch|connection refused|unable to connect/i,
+      /fetch failed|failed to fetch|load failed|attempting to fetch|connection refused|ECONNREFUSED|unable to connect/i,
     ),
     code: undefined,
   })

vitest.happy-dom.config.ts

@@ -8,19 +8,20 @@ import {sharedConfig, standaloneServer} from './vitest.config.ts'
  * browser-semantics tests here (CORS, cookies, `withCredentials`) while still talking to the
  * standalone server.
  *
- * This suite is expected to fail for now: happy-dom's CORS handling does not yet line up with a
- * real browser's, which is being worked through separately. It runs non-blocking in CI so the
- * failures stay visible without gating the other environments.
+ * The one behaviour it does not match a real browser on is stripping `Authorization` from a
+ * cross-origin redirect; `test/client.test.ts` marks those four tests as known failures.
  */
 export default defineConfig({
   test: {
     ...sharedConfig,
     environment: 'happy-dom',
-    // happy-dom otherwise defaults `location` to `http://localhost:3000`, so give it the server's
-    // origin - that is the split the browser suite is written against. Note that happy-dom still
-    // reports these requests as cross-origin and blocks them, which is part of what is being
-    // worked through separately.
-    environmentOptions: {happyDom: {url: `http://127.0.0.1:${TEST_PORT}`}},
+    // Point `location` at the server, so its requests are same-origin - the split the browser
+    // suite is written against. happy-dom otherwise defaults to `http://localhost:3000`, and
+    // every request to the server then counts as cross-origin.
+    //
+    // The key is `happyDOM`, not `happyDom`: `EnvironmentOptions` carries an index signature, so
+    // a misspelling type-checks and is then silently ignored, leaving the default URL in place.
+    environmentOptions: {happyDOM: {url: `http://127.0.0.1:${TEST_PORT}`}},
     globalSetup: standaloneServer,
     provide: {port: TEST_PORT, suite: 'happy-dom'},
   },