I read the issue and traced the most likely regression.

Issue source: “When I click on the Content Tab, I get a block”, opened by Gabo H Beaumont on May 18, 2026. Repro on the issue page: “Open a document. Open Comments View. Open the Content View. See the error.”
Source: https://seedteamtalks.hyper.media/issues/when-i-click-on-the-content-tab-i-get-a-block-

Likely cause (inference from repo code):

In frontend/packages/ui/src/document-tools.tsx, non-content tabs strip blockRef/blockRange, but the Content tab still uses the full id:

idWithoutBlock is created at lines 102-103

documentRoute still uses id at lines 105-109

Content button uses documentRoute at lines 195-209

In frontend/packages/ui/src/resource-page-common.tsx:964-988, comments routes now sync URL fragments into the route id:

on comments pages, replaceRoute({...route, id: {...route.id, blockRef, blockRange}, ...})

So if the comments view has a block fragment/selection, clicking Content carries that block-focused id back into the document route. That matches the symptom: instead of returning to the full doc, the app re-enters a block-focused/error state.

Why this looks like a regression:

document-tools.tsx got the “strip blockRef for non-content tabs” behavior earlier.

Later, commit a9a1d73a1f added fragment syncing for :comments routes.

Those two behaviors together likely created this bug.

Most likely fix:

In frontend/packages/ui/src/document-tools.tsx, make the Content tab clear blockRef/blockRange when switching from another top-level view back to content.

Safer variant: preserve block focus only when already on content/draft; otherwise use idWithoutBlock.

Tests I’d add if we implement:

frontend/packages/ui/src/__tests__/document-tools.test.tsx

render DocumentTools with an id containing blockRef

assert the Content tab href/route clears the fragment when current tab is comments

Optional integration coverage around comments→content tab switching if there’s an existing UI test harness for this flow.

Recap