A way to block upcasting given element to a widget

[Piotrek Koszuliński]

TC: there's a plugin which prints out an image e.g. as a preview of something. If image2 is loaded, it will upcast that image, so DOM structure will be changed, what perhaps will create a conflict between image2 and theoretical plugin.

Theoretically, plugin can be rewritten to make use of widgets (because if it prints out something different than it is, it is a case for widgets). But in real life developers will need to make that plugin compatible with 4.3+ without so much effort, so an easy way to prevent upcasting on certain elements will be useful.

1. First option is an attribute, but it's not yet present in data (and in fact shouldn't be at all), so it would have to be added while loading data. That means during processing them, but upcasting is done before htmlDataProcessor#dataFilter is applied, so one would have to do an additional iteration over entire structure. Not good.

2. Then, we have the possibility to overwrite image2's upcast method. This solves the problem in quite clean way, but it's not perfect. Theoretical plugin has to know about image2 and still may be broken by other widgets about which it doesn't know.

3. Better than overwriting specific widget would be to block upcasting globally. So we may add mechanism like:

editor.widgets.addUpcastMethod( function( el ) { ... } );

Returning false would block upcasting on that element. Returning other values could modify upcasting in a different way, but I don't have a clear concept yet.

Other possible method names: onUpcast, addUpcastCallback.

[Piotrek Koszuliński]

After a discussion with fredck we decided to choose the 3rd option. Proposed method name was addUpcastCallback. We should avoid using CKEDITOR.event here because of unnecessary overhead. That event would be fired for every element, so the waste would be huge.

[Piotrek Koszuliński]

Pushed ​t/11186 on dev and tests.

[Olek Nowodziński]

I pushed a minor commit to the test branch. Everything's fine except the name of the method. addUpcastMethod suggests that it's possible to extend the upcasting logic, while what we do here is a basic filtering (pre-filtering, actually). addUpcastFilter would be more convenient IMO.

​This "empty" return should be return false, right?

[Piotrek Koszuliński]

The method is named addUpcastCallback. It does not explain what this callback can do, because we don't know this yet. Currently we have only one use case for it - rejecting elements, but we may find more in the future. That's why I chose generic "Callback" rather than "Filter".

​This "empty" return should be return false, right?

No. It should be empty. That's because we don't want to block iterating over ancestors of that rejected element. E.g. in this case:

<figure class="special"><img></figure>

Someone may want to block upcasting entire special figure, but have inline image inside it.

[Piotrek Koszuliński]

Fixed on master with ​git:4d1bf91 on dev and bce4ab1 on tests.

[Jakub Ś]

#14426 was marked as duplicate.