Image2 widget upcasts and enables editing of images with contentEditable=false

[Alfonso Martínez de Lizarrondo]

Steps to reproduce

1. Add an image with contentEditable=false in a normal editor, then the image can't be edited (context menu, toolbar)

2. Enable Image2 and try again

Expected result

The image remains "static"

Actual result

It's converted into a widget and can be edited.

Other details (browser, OS, CKEditor version, installed plugins)

[Piotrek Koszuliński]

It's a tough call, but I would say that since 4.3.0 contentEditable=false has no special behaviour in the data, because contentEditable=false is only supported in form of widgets. Its existence is hence ignored by the image2 plugin. If you want to make some piece of content non-editable, create a widget for it.

The thing which may turn to be a problem is to add an upcast method before the image2's upcast, because prioritising upcasts was never implemented. The only workaround now would be to use data-widget attribute set to your widget's name. You can add this attribute for instance in a editor#toHtml listener with priority lower than 8 (upcasting is done on 8).

PS. I know this is controversial, but the whole widget system was introduced as a replacement for cE=false, so keeping support for cE=false could be odd. Especially, that it has never been official.

[Jakub Ś]

@alfonsoml perhaps you could made a use of ​​addUpcastCallback method mentioned in #11186.

This method assumes that widgets are in used in the editor, so if you are creating some general puropse plugin, you would need to use something like if (editor.widgets) { ..... This may not be desired as plugins should not know about each other. Anyway I have decided to mention this because it perhaps could be some sort of solution for you.

[Alfonso Martínez de Lizarrondo]

Replying to j.swiderski:

@alfonsoml perhaps you could made a use of ​​addUpcastCallback method mentioned in #11186.

Thanks, that's helpful because I remembered that something like that should exist, but I wasn't able to find it by searching the release notes and then I thought that using contentEditable=false should work.

Let's hope that it works when I resume work on that code because another trick that I'm using in a different plugin isn't working in this situation.