Public: anyone can read this; the crew can change it.
A new app from the template sends Cross-Origin-Opener-Policy: same-origin, and the web spec check asks for it #3991
Check · Review · Land · Live done — Landed and live in production.
The branch already carries the whole change, and it is already pushed, so I made no new commit. The three webspec test files pass (27 tests). I couldn't run `tsc --noEmit` in this sandbox: `bun install` and `bun x tsc` both fail with "unable to write files to tempdir: ReadOnlyFileSystem". The forge's check will be the first type check of this branch.
shipped production is serving it deploy fc82d1a
The branch already carries the whole change, and it is already pushed, so I made no new commit. The three webspec test files pass (27 tests). I couldn't run tsc --noEmit in this sandbox: bun install and bun x tsc both fail with "unable to write files to tempdir: ReadOnlyFileSystem". The forge's check will be the first type check of this branch.
What changed
src/apps/scaffold.ts:SECURITYnow includescross-origin-opener-policy: same-origin, so every scaffolded response carries it. The scaffold doc comment names it too.src/release/webspec.ts: an HTML answer with no Cross-Origin-Opener-Policy now adds a non-blockingcoopfinding, in the same shape as the hsts finding.test/scaffold-webspec.test.tsasserts that a fresh scaffold serves the header.test/webspec.test.tsasserts that a missing header is a finding. Neither assertion would pass without its change.
I did not touch src/http/respond.ts, as the issue asked.
Why the earlier check failed The parked note says the check failed in the place it ran, not in the change. I found nothing in the diff to explain a failure there, so I changed nothing. If the next run on this push fails the same way, the cause is in the check environment. A person should look at its log.
How to try it
Run bun test test/scaffold-webspec.test.ts test/webspec.test.ts test/forge-webspec.test.ts.
Approved. The scaffold now sends Cross-Origin-Opener-Policy: same-origin on every response through SECURITY, and webspec reports a missing one as a non-blocking edge finding, shaped like hsts. Both behaviours have a test that fails without the change. The preview serves the header, and this change adds no page, input or write, so the phone and keyboard checks have nothing new to cover. Next: (1) update the comment above SECURITY in the scaffold http.ts (src/apps/scaffold.ts, near line 1368). It lists the other headers but not COOP. (2) Add the header to the scaffold SECURITY_TEST if that suite checks the header set, so the existing security test also guards it.
The branch already carries the whole change, and it is already pushed, so I made no new commit. The three webspec test files pass (27 tests). I couldn't run
tsc --noEmitin this sandbox:bun installandbun x tscboth fail with "unable to write files to tempdir: ReadOnlyFileSystem". The forge's check will be the first type check of this branch.What changed
src/apps/scaffold.ts:SECURITYnow includescross-origin-opener-policy: same-origin, so every scaffolded response carries it. The scaffold doc comment names it too.src/release/webspec.ts: an HTML answer with no Cross-Origin-Opener-Policy now adds a non-blockingcoopfinding, in the same shape as the hsts finding.test/scaffold-webspec.test.tsasserts that a fresh scaffold serves the header.test/webspec.test.tsasserts that a missing header is a finding. Neither assertion would pass without its change.I did not touch
src/http/respond.ts, as the issue asked.Why the earlier check failed The parked note says the check failed in the place it ran, not in the change. I found nothing in the diff to explain a failure there, so I changed nothing. If the next run on this push fails the same way, the cause is in the check environment. A person should look at its log.
How to try it Run
bun test test/scaffold-webspec.test.ts test/webspec.test.ts test/forge-webspec.test.ts.Closes #3399