Skip to content

Fix inconsistent marker boundary order#19995

Open
arkflpc wants to merge 7 commits intomasterfrom
ck/19975-marker-boundary-order
Open

Fix inconsistent marker boundary order#19995
arkflpc wants to merge 7 commits intomasterfrom
ck/19975-marker-boundary-order

Conversation

@arkflpc
Copy link
Copy Markdown
Contributor

@arkflpc arkflpc commented Mar 23, 2026

🚀 Summary

Fixes incorrect order of adjacent marker boundary elements in editing downcast.


📌 Related issues


💡 Additional information

Optional: Notes on decisions, edge cases, or anything helpful for reviewers.


🧾 Checklists

Use the following checklists to ensure important areas were not overlooked.
This does not apply to feature-branch merges.
If an item is not relevant to this type of change, simply leave it unchecked.

Author checklist

  • Is the changelog entry intentionally omitted?
  • Is the change backward-compatible?
  • Have you considered the impact on different editor setups and core interactions? (e.g., classic/inline/multi-root/many editors, typing, selection, paste, tables, lists, images, collaboration, pagination)
  • Has the change been manually verified in the relevant setups?
  • Does this change affect any of the above?
  • Is performance impacted?
  • Is accessibility affected?
  • Have tests been added that fail without this change (against regression)?
  • Have the API documentation, guides, feature digest, and related feature sections been updated where needed?
  • Have metadata files (ckeditor5-metadata.json) been updated if needed?
  • Are there any changes the team should be informed about (e.g. architectural, difficult to revert in future versions or having impact on other features)?
  • Were these changes documented (in Logbook)?

Reviewer checklist

  • PR description explains the changes and the chosen approach (especially when performance, API, or UX is affected).
  • The changelog entry is clear, user‑ or integrator-facing, and it describes any breaking changes.
  • All new external dependencies have been approved and mentioned in LICENSE.md (if any).
  • All human-readable, translateable strings in this PR been introduced using t() (if any).
  • I manually verified the change (e.g., in manual tests or documentation).
  • The target branch is correct.

@arkflpc arkflpc requested review from Mati365 and niegowski March 23, 2026 15:32
Copy link
Copy Markdown

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

Bugbot Autofix prepared a fix for the issue found in the latest run.

  • ✅ Fixed: Accidentally committed review comment in source file
    • Removed the stray internal // REVIEW: note from comparemarkers.ts without altering any functional code.

Create PR

Or push these changes by commenting:

@cursor push 09d25c103e
Preview (09d25c103e)
diff --git a/packages/ckeditor5-engine/src/conversion/comparemarkers.ts b/packages/ckeditor5-engine/src/conversion/comparemarkers.ts
--- a/packages/ckeditor5-engine/src/conversion/comparemarkers.ts
+++ b/packages/ckeditor5-engine/src/conversion/comparemarkers.ts
@@ -3,7 +3,6 @@
  * For licensing, see LICENSE.md or https://ckeditor.com/legal/ckeditor-licensing-options
  */
 
-// REVIEW: Let's call this file `comparemarkers.ts` (adjust module name and imports)
 /**
  * @module engine/conversion/comparemarkers
  */

This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.

// reverse DOM order, and intersecting ranges are in something approximating
// reverse DOM order (since reverse DOM order doesn't have a precise meaning
// when working with intersecting ranges).
result.sort( compareMarkersForDowncast );
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was not needed as the markers map was already sorted in DowncastDispatcher#convert().

Comment on lines +204 to +215
// Sort the markers in a stable fashion to ensure that the order in which they are
// added to the model's marker collection does not affect how they are
// downcast. One particular use case that we are targeting here, is one where
// two markers are adjacent but not overlapping, such as an insertion/deletion
// suggestion pair representing the replacement of a range of text. In this
// case, putting the markers in DOM order causes the first marker's end to be
// serialized right after the second marker's start, while putting the markers
// in reverse DOM order causes it to be right before the second marker's
// start. So, we sort these in a way that ensures non-intersecting ranges are in
// reverse DOM order, and intersecting ranges are in something approximating
// reverse DOM order (since reverse DOM order doesn't have a precise meaning
// when working with intersecting ranges).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose to add an example, and maybe shorten the text then. It will be easier to imagine what is going on here.

Comment on lines +1338 to +1339
viewWriter.setCustomProperty( 'markerBoundaryType', 'opening', viewStartElement );
viewWriter.setCustomProperty( 'markerBoundaryType', 'closing', viewEndElement );
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose 'start' and 'end' as values, seems simpler, and we always use these two nouns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Incorrect order of adjacent marker boundary elements in editing downcast

3 participants