Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RestrictedEditing feature may produce multiple operations with the same base version #11644

Closed
ma2ciek opened this issue Apr 15, 2022 · 0 comments · Fixed by #11634
Closed

RestrictedEditing feature may produce multiple operations with the same base version #11644

ma2ciek opened this issue Apr 15, 2022 · 0 comments · Fixed by #11634
Assignees
Labels
package:restricted-editing squad:collaboration Issue to be handled by the Collaboration team. type:bug This issue reports a buggy (incorrect) behavior.

Comments

@ma2ciek
Copy link
Contributor

ma2ciek commented Apr 15, 2022

While working on the #11634, I realized that a few tests break with the new API, mainly because the Document#version check has been moved to another place where versions are checked when they are added to the History instead of before being applied.

In #11634 (comment) I debugged the issue and came to these conclusions:

  1. The addMarker() is called
  2. The applyMarkerOperation() is called the first time and a new version for the operation is created
  3. During the operation apply, but before it's done the RestrictedEditing detected that the marker has changed and is not flat (ensureNewMarkerIsFlat). As this is not a normal postfixer - model.markers.on( 'update:restrictedEditingException', ensureNewMarkerIsFlat( editor ) ); - the ensureNewMarkerIsFlat is called just after detecting the update of the marker.
  4. The ensureNewMarkerIsFlat detects a marker that is not flat and updates it.
  5. The udpateMarker() is called
  6. The applyMarkerOperation() is called the second time and a new version for the operation is created - the same as during the 2. step.
  7. The second operation is applied successfully and the document version is incremented.
  8. The first operation can't be applied - the version of the operation is the same as the second one.

@ma2ciek ma2ciek added type:bug This issue reports a buggy (incorrect) behavior. package:restricted-editing labels Apr 15, 2022
@scofalik scofalik added the squad:collaboration Issue to be handled by the Collaboration team. label Apr 22, 2022
@scofalik scofalik self-assigned this Apr 22, 2022
@CKEditorBot CKEditorBot added the status:planned Set automatically when an issue lands in the "Sprint backlog" column. We will be working on it soon. label Apr 22, 2022
@scofalik scofalik assigned ma2ciek and unassigned scofalik Apr 22, 2022
scofalik added a commit that referenced this issue Apr 26, 2022
Feature (engine): Improved the `History` API. Changes summary is in the related issue. Closes #11226.

Fix (restricted-editing): Standard editing mode postfixers will no longer create marker operations with invalid base versions. Closes #11644.

MINOR BREAKING CHANGE: The `Document#version` became a getter and changing it is now impossible. `document.applyOperation()` increments the `Document#version`, so changing it directly should not be necessary. However, for advanced use cases, it can be changed using the new `History#version` property.
@CKEditorBot CKEditorBot removed the status:planned Set automatically when an issue lands in the "Sprint backlog" column. We will be working on it soon. label Apr 26, 2022
@CKEditorBot CKEditorBot added this to the iteration 53 milestone Apr 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:restricted-editing squad:collaboration Issue to be handled by the Collaboration team. type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants