Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Placeholder of an empty list item stays visible on a collaborator's editor using Firefox after text is typed by another user using Chromium

未關閉
#3,245 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
58/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
react, typescript
領域
frontend

研究方向

Start by tracing how the empty-block placeholder is recalculated when local typing changes a list item, then compare that with the remote Yjs update path in the editor. Reproduce with Firefox and Chromium on the demo; test whether the fix also handles typing in the reverse direction and other block types. Done when the placeholder disappears in Firefox after remote text arrives, without breaking local typing.

由索引模型根據 Issue 內容生成。

描述

What's broken?

In a collaborative session, the gray placeholder of a list item doesn't go away in Firefox when the other user types in that item from Chromium. The block's text syncs correctly, but the "List" placeholder stays visible right after the text.

It happens on every new bullet item the Chromium user creates and types into. In the Chromium editor everything looks right: no placeholder once there's text.

Reproduced on the official demo: https://www.blocknotejs.org/demo

What did you expect to happen?

When a block that was empty gets content from a remote collaborator, its placeholder should go away on every client, the same as it does for local typing.

Steps to reproduce
  1. Open https://www.blocknotejs.org/demo in Firefox and copy the collaboration URL (/demo#<room>).
  2. Open the same URL in Chromium / Chrome.
  3. In Chromium, put the cursor at the end of a bullet list item and press Enter to create a new, empty bullet item.
  4. In Firefox, the new empty item shows the "List" placeholder, as expected.
  5. In Chromium, type some text into that new item.
  6. In Firefox: the text shows up, but the gray "List" placeholder stays visible after it.
  7. Repeat with another new item and you get the same result.
What browsers are you seeing the problem on?
  • Firefox: the editor where the stale placeholder appears
  • Chromium: the editor where the user types
BlockNote version

The version deployed on blocknotejs.org/demo as of 2026-10-23

Environment

Linux (Ubuntu), Firefox and Chromium side by side on the same machine

Additional context

See the attached video: Firefox on the left, Chromium on the right.

It looks like the empty-block placeholder decoration isn't recalculated on the Firefox client when the block's content comes from a remote Yjs update rather than a local transaction. It may be tied to where the Firefox selection sits, since its caret is in or near that block. This is only a guess and hasn't been checked in the code. We haven't tested the reverse case (typing in Firefox, watching in Chromium) or other block types (paragraph, numbered list, checklist), which could help narrow it down.

https://github.com/user-attachments/assets/2bb0640d-219d-4f24-92f8-1736ea075e55

主要語言
TypeScript
星號
10.3k
分支
780
平均合併
2 天 22 小時
30 天內合併 PR
48

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

TypeCellOS/BlockNote 的其他 Issue

查看 TypeCellOS/BlockNote 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。