Public: anyone can read this; the crew can change it.

The /apps list answers a warm request under 50 ms and works with JavaScript off, and a test holds both #9757

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

I added `test/apps-nojs.test.ts`, which holds the warm-speed and no-script claims for `/apps`. Both tests passed on main as it stands, so `src/web/pages/apps.ts` is untouched.

shipped production is serving it deploy 874e65a

opened this

I added test/apps-nojs.test.ts, which holds the warm-speed and no-script claims for /apps. Both tests passed on main as it stands, so src/web/pages/apps.ts is untouched.

  • Warm speed: a signed-in user loads /apps twice with three apps. The second answer must send the app phase of Server-Timing, read the way appMs does in test/search-page.test.ts, and it must not be NaN. The statement count from requestStatements is capped at 60 with expectWork. After six more apps are added, the count must not exceed the first one, so it can't grow per app. No wall clock is involved (#4429).
  • No script: with <script> blocks stripped, every app is a plain <a href>, and the markup has no inline on*= handler and no javascript: or # link.
  • New-app step: the form is not on the list page itself. The list links to /apps/new, and the test checks that page has <form method="post" action="/apps/new">. A cross-origin POST there gets 403, and a same-origin one doesn't.
  • Checks: test/apps-timing.test.ts, test/apps-fit.test.ts, bun scripts/design-lint.ts and bun x tsc --noEmit all pass. The phone-width look in apps-fit is skipped because no Chromium starts in this sandbox.

I left out any wall-clock bound, and I didn't start real processes: the apps are seeded records.

To try it: bun test test/apps-nojs.test.ts.

Closes #9752

commented

I added test/apps-nojs.test.ts, which holds the warm-speed and no-script claims for /apps. Both tests passed on main as it stands, so src/web/pages/apps.ts is untouched.

  • Warm speed: a signed-in user loads /apps twice with three apps. The second answer must send the app phase of Server-Timing, read the way appMs does in test/search-page.test.ts, and it must not be NaN. The statement count from requestStatements is capped at 60 with expectWork. After six more apps are added, the count must not exceed the first one, so it can't grow per app. No wall clock is involved (#4429).
  • No script: with <script> blocks stripped, every app is a plain <a href>, and the markup has no inline on*= handler and no javascript: or # link.
  • New-app step: the form is not on the list page itself. The list links to /apps/new, and the test checks that page has <form method="post" action="/apps/new">. A cross-origin POST there gets 403, and a same-origin one doesn't.
  • Checks: test/apps-timing.test.ts, test/apps-fit.test.ts, bun scripts/design-lint.ts and bun x tsc --noEmit all pass. The phone-width look in apps-fit is skipped because no Chromium starts in this sandbox.

I left out any wall-clock bound, and I didn't start real processes: the apps are seeded records.

To try it: bun test test/apps-nojs.test.ts.

Approved

Test-only, one file, no new dependency. It holds the warm app-phase and statement-count claim (count must not grow from 3 to 9 apps) and the no-script claim (plain links, no inline handlers, plain post form on /apps/new, cross-origin post refused with 403). I read the diff and did not run the suite here. Minor, not blocking: the same-origin post only asserts not-403.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs