Blort browser audit

Open /boards?folder=42&sort=updated while signed out. Both recordings show the same login form; the change is in the return URL stored by the route guard.

Behavior	Before fix	After fix
Return destination passed to login	/boards	/boards?folder=42&sort=updated
Query parameters retained	None	folder=42 and sort=updated
Visible login form	Unchanged	Unchanged

The recordings capture the webpage viewport, so they do not show the browser's address bar. The automated assertion reads the login URL's redirect parameter: it failed with /boards before the fix and passes with the complete original destination afterward. This particular regression checks the redirect into login; it does not sign in or demonstrate a folder being opened afterward.

• Regression: anonymous protected navigation preserves the complete destination in e2e/auth.spec.ts.
• Reproduce: With no session, open /boards?folder=42&sort=updated.
• Before: Login receives redirect=/boards; folder and sort state disappear.
• Cause: The Next route guard stores only pathname in the login continuation.
• Fix: src/proxy.ts includes both the pathname and query string.
• Expected: The login continuation is /boards?folder=42&sort=updated.
• Recording: artifacts/e2e/bugs/auth-query-loss/before/video.webm. That directory also contains the pre-fix screenshot and Playwright trace.
• After: The matching passing browser recording is copied to artifacts/e2e/bugs/auth-query-loss/after/ by the evidence report.

The browser exercises the real Next route guard. This failure is independent of backend authentication correctness.

• Regression: login refuses a backslash redirect to another origin in e2e/auth.spec.ts.
• Reproduce: Open login with redirect=/\evil.example/steal, then log in successfully.
• Before: The browser navigates to http://evil.example/steal. The recording displays a locally intercepted destination; no external service receives the test traffic.
• Cause: A prefix check accepts a slash followed by a backslash as local. Browser URL parsing normalizes the backslash into a slash and interprets the result as a hostname.
• Fix: getSafeLocalRedirect in src/lib/utils/auth-redirect.ts uses URL parsing, checks the resolved origin, and returns a normalized local path. Login, verification, and the auth server layout all consume that helper.
• Expected: Untrusted destinations fall back to the normal in-app landing flow.
• Recording: artifacts/e2e/bugs/auth-open-redirect/before/video.webm. The directory also contains the pre-fix screenshot and Playwright trace.
• After: artifacts/e2e/bugs/auth-open-redirect/after/.

Absolute and protocol-relative variants are also covered. This is browser-level redirect proof, with synthetic credentials and an isolated API.

• Regression: signed-in login navigation follows its local destination in e2e/auth.spec.ts.
• Reproduce: With a verified session, open /login?redirect=%2Fchange-email%3Ffrom%3Dexisting-session.
• Before: The auth layout redirects through / to /boards, discarding the intended page and its query.
• Cause: The server layout honors MCP authorization continuations but ignores the ordinary redirect parameter for already authenticated visitors.
• Fix: src/app/(auth)/layout.tsx follows the validated local redirect after checking the MCP continuation.
• Expected: The existing session goes directly to /change-email?from=existing-session without another login request.
• Recording: artifacts/e2e/bugs/auth-signed-in-continuation/before/video.webm. The directory also contains the pre-fix screenshot and Playwright trace.
• After: artifacts/e2e/bugs/auth-signed-in-continuation/after/.

This regression exercises the server-rendered auth layout, independently of client login.

• Regression: successful verification refreshes the session before following the original destination in e2e/auth.spec.ts.
• Reproduce: With an unverified session, open /verify-code?redirect=%2Fchange-email%3Fverified%3D1 and submit a valid six-digit code.
• Before: Verification succeeds and refreshes the session, then navigates through /?new-user=true to pricing instead of the requested destination.
• Cause: The success handler preserves the ordinary continuation during preceding auth navigation but never uses it after verification.
• Fix: src/components/auth/verify-code-page.tsx follows the validated local destination after the existing session refresh and MCP continuation check.
• Expected: The browser reaches /change-email?verified=1, with /auth/refresh observed after /auth/verify.
• Recording: artifacts/e2e/bugs/auth-verification-continuation/before/video.webm. The directory also contains the pre-fix screenshot and Playwright trace.
• After: artifacts/e2e/bugs/auth-verification-continuation/after/.

The API supplies verification results; the real client owns refresh ordering and navigation.

• Regression: Backspace from a cleared middle code slot clears the preceding digit in e2e/auth.spec.ts.
• Reproduce: Enter 123456, focus digit 3, and press Backspace twice.
• Before: The first press clears digit 3; the second leaves digit 2 as 2 and focus remains in the empty third slot.
• Cause: The internal code retains a space placeholder for a middle hole. The handler treats that space as a nonempty digit and repeatedly clears the same slot.
• Fix: src/components/auth/otp-input.tsx checks the trimmed digit and moves left when it is empty. It also avoids writing a negative array index at the first slot.
• Expected: The second press clears digit 2 and focuses it while later digits remain unchanged and incomplete verification stays disabled.
• Recording: artifacts/e2e/bugs/auth-otp-backspace/before/video.webm. The directory also contains the pre-fix screenshot and Playwright trace.
• After: artifacts/e2e/bugs/auth-otp-backspace/after/.

The browser uses actual keyboard events against the rendered controlled inputs.

Severity: medium. A temporary API failure leaves the board card displaying the opposite of the persisted favourite state. The next click sends the inverse operation, so the user's retry never achieves the intended result.

Reproduce: open the board library, click an unliked card's star while POST /board/1/like returns 500, wait for the error toast, then click the star again. Before the fix, the recorded requests are POST followed by DELETE. Expected: POST followed by POST, followed by the board appearing under Liked. Starting from a liked board reproduces the reverse sequence: DELETE followed by POST instead of DELETE followed by DELETE.

Root cause: BoardCardComponent initialized local isLiked from props, changed it inside mutationFn, and only handled success. Failed requests never restored the state; later refreshed props also could not replace the stale local value.

Fix: keep only a temporary optimistic override, pass the target favourite state explicitly into the mutation, clear the override on error, and clear it after the successful list refresh. Disable the star during the request to prevent competing clicks. aria-pressed now exposes the visible favourite state to assistive technology.

The regression cases are failed like restores saved state so retry performs the same operation and failed unlike restores saved state so retry performs the same operation in e2e/boards.spec.ts. Both failed before the fix on the intended request sequence assertion. The baseline also reported a separate fixture teardown error for an unimplemented survey endpoint; that error does not explain the failed request sequence.

Before videos, screenshots, trace, and failure context:

• artifacts/e2e/bugs/favourite-rollback/before/like/
• artifacts/e2e/bugs/favourite-rollback/before/unlike/

After videos are retained from the passing regression run under artifacts/e2e/bugs/favourite-rollback/after/.

Severity: medium. Every persisted board preference can display the opposite of its saved setting after a full page reload, including Dark Mode. The visual switch and its accessible checked state disagree with the current browser preference.

Reproduce: open /settings?tab=board, turn Mini map on, and reload. Before the fix, its switch returns visually to off even though localStorage still contains miniMap=true. The same failure occurs when changing Background Dots, Connection Animations, Proximity Connect, or Dark Mode away from their defaults.

Root cause: the Zustand store's initializer reads localStorage and the theme cookie in the browser but returns hard-coded defaults during SSR. Installed Zustand uses getInitialState() as React's hydration snapshot. The server and browser initial snapshots therefore disagree. React reports a hydration attribute mismatch and does not repair the switch's checked DOM attributes when it considers the current client value unchanged.

Fix: initialize the store with identical defaults on the server and browser, then apply persisted browser values to its current state using the existing store API. Zustand retains the stable initial snapshot for hydration and publishes the persisted current snapshot immediately afterward. Existing getters, setters, localStorage keys, and the theme cookie remain compatible.

Regression cases in e2e/navigation.spec.ts:

• Mini map preference persists across a reload
• Background Dots preference persists across a reload
• Connection Animations preference persists across a reload
• Proximity Connect preference persists across a reload
• dark mode changes the rendered theme and persists across reload

All five failed on the intended persisted switch assertion before the fix. Before recordings, screenshots, trace and failure contexts are in artifacts/e2e/bugs/settings-hydration/before/{mini-map,background-dots,connection-animations,proximity-connect,dark-mode}/. After recordings are retained under artifacts/e2e/bugs/settings-hydration/after/ once verified.

Reproduction: Enter spaces in the assistant composer. The Send button was enabled, although submission silently rejected the empty trimmed prompt.

Root cause: The button checked raw input while the submit handler checked trimmed input.

Fix: The disabled condition now checks input.trim(), consistently preserving image-only submissions.

Regression: e2e/canvas.spec.ts — whitespace-only prompts cannot be sent. The Chromium browser test failed before the repair for this intended reason.

Evidence: before video, before screenshot, before trace. After video is collected by the verification run.

Scope: these tests execute the real Next.js application against an isolated HTTP backend. For the viewer case they prove the frontend attempted a forbidden mutation; they do not claim the production backend accepted it.

Reproduction: Open shared board3 as a viewer, then drop a TXT file. The browser initiated POST /source/text with boardId3 despite disabled creation controls.

Root cause: The canvas file-drop hook had no permission gate; disabling toolbar controls did not cover drag-and-drop.

Fix: Flow disables the drop boundary for viewers and previews. The hook also checks current read-only state before creation and after asynchronous text-file reads.

Regression: e2e/sources.spec.ts — viewer cannot import files by dropping them onto a read-only board. The Chromium browser test failed before the repair for this intended reason.

Evidence: before video, before screenshot, before trace. After video is collected by the verification run.

Scope: these tests execute the real Next.js application against an isolated HTTP backend. For the viewer case they prove the frontend attempted a forbidden mutation; they do not claim the production backend accepted it.

Reproduction: Open /board/1?preview=1, then drop a TXT file. A text node appeared and a source creation request was sent.

Root cause: Preview hid editing controls but left file-drop listeners active.

Fix: Preview now disables the canvas drop boundary and uses read-only editor state.

Regression: e2e/sources.spec.ts — preview boards cannot import files through drag and drop. The Chromium browser test failed before the repair for this intended reason.

Evidence: before video, before screenshot, before trace. After video is collected by the verification run.

Scope: these tests execute the real Next.js application against an isolated HTTP backend. For the viewer case they prove the frontend attempted a forbidden mutation; they do not claim the production backend accepted it.

Reproduction: Open a board containing text with ?preview=1. The rendered Tiptap editor had contenteditable=true despite preview mode.

Root cause: FlowPage treated copied boards and viewer permissions as read-only but omitted preview mode.

Fix: Preview enters the same read-only state as copies, disabling text editors and the chat composer.

Regression: e2e/sources.spec.ts — preview text content is readable but cannot be edited. The Chromium browser test failed before the repair for this intended reason.

Evidence: before video, before screenshot, before trace. After video is collected by the verification run.

Scope: these tests execute the real Next.js application against an isolated HTTP backend. For the viewer case they prove the frontend attempted a forbidden mutation; they do not claim the production backend accepted it.

Severity: medium. A slow account request can erase the profile description that a user has already typed, including a draft they intended to retry after a failed save.

Reproduce: open Settings with the initial account request slower than the social-profile requests, type a niche description as soon as the field appears, reject its first save, and allow the account request to finish. Before the fix, the existing account initialization effect replaces the user's draft with the saved account description. The recording captured the text disappearing immediately after a failed save.

Root cause: ProfileTab exposes its description field when the independent social-profile loader finishes. Its didInitNiche guard is set only when account data arrives, so a user edit during that earlier window does not prevent the account effect's setDescription from overwriting the draft.

Fix: mark the existing initialization guard as complete when the user edits the description. Late account data still initializes an untouched field, while an explicit user edit takes precedence.

The regression in e2e/navigation.spec.ts is failed profile niche save preserves edits while account loads and can be retried. It holds the first account response until the user has typed and received a rejected save, then releases the response and requires the draft to remain available for retry and persist after reload.

The original naturally occurring failure was failed profile niche save preserves edits and can be retried; it failed on the immediate draft-preservation assertion (expected Independent travel creators, received an empty string), independently of transport-fixture teardown. The saved trace shows social requests resolving before the initial account request and the user editing in between.

The deterministic delayed-account case was also run against the original production code and failed on the same draft assertion: expected Independent travel creators, received Previously saved niche. That separate reproduction is archived under artifacts/e2e/bugs/profile-draft-race/before/deterministic/.

Before recording, trace, screenshot, and failure context: artifacts/e2e/bugs/profile-draft-race/before/. After recording is saved under artifacts/e2e/bugs/profile-draft-race/after/ after the deterministic regression passes.