-
Notifications
You must be signed in to change notification settings - Fork 55
Description
Description
For some time now, CKEditor will sometimes downcast markers as attributes on elements, for example data-suggestion-start-before
or data-suggestion-end-after
. So if an equation is inserted with track changes enabled, the result of an editor.getData()
call will be something like:
<math
xmlns="http://www.w3.org/1998/Math/MathML"
data-suggestion-end-after="insertion:e9b71d7f34f79a851e753d4518b69e1c5:12345"
data-suggestion-start-before="insertion:e9b71d7f34f79a851e753d4518b69e1c5:12345"
>
<mo>∞</mo>
</math>
When this HTML us upcast, this code will store those marker data-
attributes in the formula
property on the model, and will use that property to produce HTML in subsequent downcasts, whether the suggestion should still be present or not.
This means that if you accept the suggestion, then serialize/downcast the model to an HTML string, then reload/upcast it, the suggestion will re-appear when it shouldn't.
Environment
I'm using @wiris/mathtype-ckeditor5
v7.24.4. I haven't been able to upgrade/test a more recent version, but from looking at the code I'm pretty sure it will still reproduce.
Steps to reproduce
- Create an editor with the MathType plugin and the CKEditor track changes plugin installed
- Enable track changes
- Insert an equation
- Call
editor.setData(editor.getData())
(this will cause this code to create amathml
model element whoseformula
attribute contains an HTML string that include thedata-suggestion-
HTML attributes) - Accept the equation insertion suggestion
- Call
editor.setData(editor.getData())
Expected result
The equation is plan content -- not an insertion suggestion
Actual result
The equation is an insertion suggestion
Other details
It's not safe for the plugin to assume that during upcast any/all attributes on the view are part of the MathML markup because markers and potentially other editor features might downcast into attributes that get stored on the <mathml>
HTML element. Potential options I can think of:
- The plugin could have an allow-list of actual MathML attributes to include when creating the HTML string to put in the
formula
model attribute - The plugin could ignore all
data-
attributes, or specificallydata-.+-(start|end)-(before|after)
attributes to target these marker attributes specifically - The plugin could change its upcasting/downcasting strategy so there is some wrapper element around the
<mathml>
element, which would ensure that other editor features like markers would apply their attributes to that wrapper element rather than the<mathml>
element
I think (3) is probably the best/safest option, but (1) might be a decent solution as well. (2) seems risky as it wouldn't necessarily ensure that the plugin would play nicely with other editor features that might write out attributes other than data-
attributes.