Inconsistent ACF rule application between inline editor and standard editor

[Kevin Kamel]

This is a refinement of the ticket I filed in #10661. I am including a better example to show the problem.

See example, which links to remote assets on ckeditor. To use this file you can simply view it on your desktop.

The example loads 4 editor instance for standard toolbar, shared toolbar (inline) and floating toolbar (inline) and default toolbar (inline).

You will see that for this simple example the "marker" class from the style drop down does not display for any of the "inline" editors, however does show for the standard editor without a problem.

These are all default examples. The standard editor has ACF rules that allow class/id for spans, whereas the inline editor does not. This needs to be consistent.

Shouldn't the style drop down itself be loading ACF for style properly, as otherwise the style drop down cannot work??

There is no documentation for sample space or floating space - instead we can only read the examples that are for each plugin. The examples themselves have this same error. If you select "marker" and attempt to apply it to content it cannot work, and the class is stripped immediately.

See test for reasons.

[Kevin Kamel]

example showing shared/floating/default inline editor stripping styles whereas standard editor does not

[Piotrek Koszuliński]

I confirm that editor with sharedspace plugin does remove span.marker. All other editors preserve those spans, although they are not visible due to styling issues in our samples (reported in other ticket, which I cannot find right now).

This seems to be a problem with loading order - toolbar for an editor using shared space is perhaps created too late.

[Piotrek Koszuliński]

Simple, although not convenient workaround for now is to add all styles to ACF using config.extraAllowedContent.

[Kevin Kamel]

Thanks for looking.

I am now using "config.extraAllowedContent" in the meantime to continue upgrading my application code, but I like the idea of ACF. Being able to control the content that is entered is so much better than dealing with the random garbage that people paste in from the internet.

[Piotrek Koszuliński]

It turns out that sharedspace plugin creates toolbar (fires editor#uiSpace event) too early - on plugin#afterInit, instead of on editor#loaded, so editor#styleSet is not fired yet. It seems to be enough to do this on editor#loaded but with higher than creatores/themedui.js priority.

[Piotrek Koszuliński]

Pushed ​t/10662 on dev and tests.

[Piotrek Koszuliński]

I attached sample for easier testing - in all editors text should be marked with yellow bg.

[Piotr Jasiun]

I've added use strict to tests and passed review.

Samples still doesn't work, but this is because of this bug: #10150.

[Kevin Kamel]

I think what pjasiun means is that the "sharedspace.html" doesn't highlight due to bug #10150 - but the example with an in document stylesheet as Reinmar posted in "10662.html" does work now.

Pretty sweet, thanks

[Piotr Jasiun]

Exactly. 10662.html works fine, but because of #10150 sharedspace.html (but also inlineall.html, inlinebycode.html and other samples using inline) does not show marked text.

[Piotrek Koszuliński]

Yes - #10150 is a separate issue and it is not even related to dev code, but more to our samples.

I fixed this issue on master with ​git:402f68f and tests with 2647673.