You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(ui): rich text fields not read-only inside tabs on trashed and locked documents 3.x (#17791)
### What?
Rich text fields nested inside a `tabs` field stayed editable on trashed
documents (and on documents opened read-only after a document lock),
while every other field on the same document was correctly disabled.
### Why?
Rich text renders as a server component, so `RenderField` returns the
pre-rendered RSC and discards the client-side `readOnly` prop that
`RenderFields` threads down. Its read-only state comes solely from the
`readOnly` argument passed into `buildFormState` by the document view
(`readOnly: isTrashedDoc || isLocked`).
Every branch of `addFieldStatePromise` forwards that value into its
children — `array`, `blocks`, `group`, `row`/`collapsible`, `tab` —
except the `tabs` branch, which omitted it. Form state for anything
under a tabs field was therefore built with `readOnly: undefined`,
`renderField` fell back to permissions, and the field was rendered with
`readOnly: false`.
Fields that aren't server-rendered were unaffected, because they receive
`readOnly` through the client-side `RenderFields` prop chain — which is
why this looked arbitrary in practice: on the same page, a rich text
field in one block is disabled while one inside a tabbed block is
editable.
This is the same class of bug as #13579, which fixed rich text read-only
for locked documents but only for fields that are not inside tabs.
### How?
- Forward `readOnly` in the `tabs` branch of `addFieldStatePromise`.
- The edit view's `onChange` never sent `readOnly` with subsequent
form-state requests, so any field re-rendered by one of those requests
came back editable on a trashed or locked document. It now sends
`isTrashed || isReadOnlyForIncomingUser`, mirroring the initial server
render. This one is hardening rather than a visible fix:
`LexicalProvider` memoizes `initialConfig.editable` and keys the
composer on it, so an editor mounted read-only won't flip back on its
own — but the form state was wrong, and any other server-rendered custom
`Field` that honours prop changes would be affected.
Regression test added to `test/trash`: the collection gets a rich text
field and a rich text field inside a `tabs` field, and the
trashed-document edit view test asserts both render
`contenteditable="false"` / `aria-readonly="true"`. Verified red before
the fix and green after, on this branch and on `3.x`.
v3 backport of #17790 — see #17789.
---------
Co-authored-by: Patrik Kozak <35232443+PatrikKozak@users.noreply.github.com>
0 commit comments