RichEditor: pasted content bypasses toolbarButtons() restrictions

[KianAcquoy]

Problem

As far as I can tell, toolbarButtons() only hides the buttons in the UI. When you paste formatted content into a field with for example ->toolbarButtons(['bold']), the formatting stays in. It passes validation, gets saved to the database and is rendered on output. I tested this with headings, but since the extension list is static I assume the same applies to lists, alignment, tables etc.

Steps to reproduce

1. RichEditor::make('title')->toolbarButtons(['bold'])
2. Copy an <h2> or a bullet list from any web page and paste it into the field
3. Save. The heading node is still there in the saved state and in the rendered output

Expected

If a button isn't in the toolbar I'd expect the editor to not accept that formatting at all, also when pasting.

For now we work around it in our app by sanitizing the document in a mutateDehydratedStateUsing() hook. But am interested to know if other people have this issue too.

[vynazevedo]

I would separate two configuration contracts here: which editing commands are visible, and which document nodes/marks are allowed. Automatically deriving the latter from the toolbar could remove previously stored content simply because a screen hides some controls.

For an explicit formatting policy, the tests should cover paste, initial hydration from saved HTML/JSON, programmatic insertion, and save/reload. A paste-only filter cannot enforce the same policy for those other entry points. Similarly, stripping heading tags without defining how their children are retained can lose text rather than merely remove formatting.

For your example, a useful assertion is “pasting a heading preserves its text as a paragraph, keeps allowed bold marks, and remains unchanged after another save/load cycle.” Also test links, nested lists, and custom blocks independently; toolbar groups do not necessarily map one-to-one to schema extensions.

The current RichEditor rendering code passes the TipTap extensions separately from rendering toolbar buttons, which supports treating these as distinct concerns. I haven't run a browser reproduction or established an existing public API for a document allowlist. I'd favor an explicit policy option over changing toolbarButtons() into a destructive content filter.