Plan

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

I reviewed the issue at https://seedteamtalks.hyper.media/issues/when-i-click-on-the-content-tab-i-get-a-block- and the strongest code-level explanation is a routing regression: the comments view now syncs block fragments into route.id, but the Content tab still navigates with that block-focused id instead of a clean document id. The most likely fix is in frontend/packages/ui/src/document-tools.tsx, where the Content tab should clear blockRef/blockRange when switching back from comments to content.

Key files: frontend/packages/ui/src/document-tools.tsx, frontend/packages/ui/src/resource-page-common.tsx

This is an inference from the issue repro plus current code; I did not run the app in this read-only pass.

If you want, next I can turn this into a concrete patch plan or implementation diff.