What’s broken?

In Safari and WebKit based desktop applications, BlockNote's placeholders is not being cleared after text is started to be entered into a block or document. The document updates and the entered text persists correctly, but the placeholder is stilling being displayed inline beside the text until Safari or the application is refreshed. This affects both the emptyDocument placeholder and the default placeholder.

What did you expect to happen?

The empty document and default placeholder should disappear immediately when starting to type into a block in Safari and WebKit-based desktop frameworks as happens in Chrome. Where the placeholder disappears immediately after the first character is entered.

Steps to reproduce

1. Setup/Create a BlockNote editor.
2. Open the editor in Safari or a WKWebView based desktop application (I am using Electrobun, Tauri is probably the same).
3. Focus an empty document and type anything. Empty editor placeholder text remains beside the entered text if set.
4. Press Enter to create another block and type text. Default placeholder text remains beside the entered text.
5. Repeat in Chrome. Both placeholders disappear immediately after typing.

BlockNote version

0.51.4

Environment

Safari 27.0 (22625.1.20.11.3), macOS 27.0 (26A5368g), Electrobun 1.18.1 (WKWebView), React 19.1.0

Additional context

I got Codex to investigate the bug and it returned the following notes:

BlockNote 0.51.4 injects placeholder rules from PlaceholderExtension using a selector shaped like:

.placeholder-selector-... .bn-block-content[data-is-empty-and-focused]:has(.ProseMirror-trailingBreak:only-child)::after

In Chrome, typing removes the placeholder immediately (::after changes from the configured string to none, and the empty/focused decoration is removed). In Safari/WebKit, the editor contains and persists the entered text while the generated placeholder pseudo-content remains visible. Changing focus causes it to disappear.

This strongly suggests a WebKit style-invalidation issue involving the dynamically injected :has(...)::after rule, rather than an editor-state or persistence failure. The behavior was reproduced directly in Safari and in a native WKWebView, with Chrome used as the working control.

Contribution

• I'd be interested in contributing a fix for this issue

Sponsor

• I'm a sponsor and would appreciate if you could look into this sooner than later 💖