Rich text reports display-only link resolution as an edit: setContent(x, false) doesn't suppress the update in Tiptap 3

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#231 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
78/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, react
Lĩnh vực
frontend, testing

Hướng nghiên cứu

Bắt đầu tại packages/editor-ui/src/components/settings/inputs/RichTextInput.jsx và kiểm tra bốn lời gọi setContent quanh các dòng 477, 487, 500 và 516, cùng với trình xử lý onUpdate. Cập nhật các lời gọi để ngăn phát sinh cập nhật và thêm một bài kiểm tra component cho liên kết có slug đích đã thay đổi. Hoàn tất khi onChange không được gọi trong quá trình phân giải hiển thị và biểu mẫu vẫn ở trạng thái sạch; chạy bài kiểm tra component liên quan và các bài kiểm tra stableLink.test.jsx hiện có.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug editor

A rich-text field is meant to resolve its internal links for display without counting that as an edit. It counts it anyway: the field calls onChange, so opening a widget can mark the page as changed when nothing was edited.

What happens

RichTextInput keeps internal links pointing at current slugs for display. The comment above its sync effect says this is display-only:

setContent with emitUpdate=false means this is display-only — it does NOT fire onUpdate/onChange, so the field isn't dirtied and the stored value is untouched until a real edit.

But the call passes a bare false:

editor.commands.setContent(displayValue, false);

(packages/editor-ui/src/components/settings/inputs/RichTextInput.jsx ~477; the same call at ~487, ~500 and ~516.)

In Tiptap 3 the second argument is an options object (setContent(content, { emitUpdate, parseOptions, errorOnInvalidContent })), and emitUpdate defaults to true. Destructuring false finds no emitUpdate, so the default applies and the update is emitted. The editor's onUpdate (~449) then calls onChange(editor.getHTML()).

So whenever resolveForDisplay(value) differs from what the editor holds (for example, a link to a page whose slug has changed since the link was saved), the resolved HTML is reported as a change to the field. Expected: the page stays clean, and the stored value keeps its original href until a real edit.

The other three calls (switching back from source mode, source blur, collapsing the expanded editor) call onChange themselves right after, so for them the extra update is harmless but redundant.

Fix

Pass the options object in all four places:

editor.commands.setContent(displayValue, { emitUpdate: false });

Then add a test that mounts the field with a link whose target slug has changed and checks that onChange isn't called and the form isn't dirty. The current link tests (stableLink.test.jsx) use a headless editor, so they don't cover the component.

How it was found

Code review during the dependency upgrades, checked against Tiptap's setContent signature (the same in 3.18 and 3.32). Not yet reproduced in the editor UI.

Ngôn ngữ chính
JavaScript
Star
162
Fork
6
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của tsiger/widgetizer

Tất cả issue của tsiger/widgetizer

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.