Load JavaScript Skin Extensions
Some rendering macros are displayed using JavaScript code. Loading the JavaScript code improves the WYSIWYG aspect of the editor but it may cause problems if the JavaScript code interferes with the CKEditor code or if it changes content outside of the macro output boundaries.
It was introduced before we implemented the in-place WYSIWYG edit mode. The big difference between the standalone and in-place WYSIWYG edit modes is:
the standalone WYSIWYG edit mode uses an iframe to implement the editable area, so the edited content is isolated from the top page (that has the breadcrumbs, the title, the action buttons, etc.); this means we can control which JavaScript code is loaded
for the in-place WYSIWYG edit mode the edited content is not isolated from the top page, so it is affected directly by the CSS and JavaScript code that is already loaded on the page
For this reason, when we implemented the in-place edit mode we ignored the “Load JavaScript Skin Extensions” configuration, because there was already JavaScript code loaded on the page so we couldn’t really protect (isolate) the edited content.
This means that now there is an inconsistency between the standalone and in-place editor when it comes to rendering macros that rely on JavaScript code. Such macros are common, so this difference is more and more visible.
Even if we’re planning to use the in-place edit mode for page creation also, the standalone (iframe-based) edit mode will still be used for some time for TextArea properties, so it makes sense to have a consistent behavior. Thus, I propose to enable the loading of the JavaScript code in the standalone WYSIWYG editor by default
+1 on my side.
We could also remove this configuration option, but I’m worried that some users (e.g. that have disabled the in-place edit mode) will ask how to go back to the previous behavior, and it will be harder for them without this configuration option.
I assume some macros could break the editor/the edited content when their JavaScript code is executed, e.g., by adding HTML elements outside the macro.
Yes, exactly. They might be using rendering macros that rely on JavaScript, but that don’t play well with the WYSIWYG editor. And yes, the main problem is when the JavaScript code of a rendering macro modifies content outside the macro markers, and this gets saved.
It’s a bit more complicated than I thought. Another big difference between the in-place and the standalone WYSIWYG edit modes is the root editable element:
a DIV nested inside the HTML BODY for the in-place editor
the BODY element for the standalone editor
The difference is relevant for our discussion because:
it’s very common for a JavaScript module to add hidden stuff at the end of the BODY element (modals, dropdowns, etc.)
it’s very uncommon for a JavaScript module to add (hidden) stuff inside the page content, unless it’s inside the output of a macro
This means that loading of the JavaScript code doesn’t have the same effect on the standalone and the in-place edit mode: it’s more dangerous for the standalone edit mode. For this reason, when I introduced the loadJavaScriptSkinExtensions configuration I limited its effect to JavaScript modules that are marked as safe.
We have two options:
change the root editable for the standalone edit mode (e.g. use a DIV inside the BODY element): not trivial and unsafe, since this is a core CKEditor feature, so it can have unexpected side effects
continue to apply loadJavaScriptSkinExtensionsonly to JavaScript modules that are marked as safe, but this means we’ll still have an inconsistency between in-place and standalone mode:
in-place: no need to mark JavaScript module as safe to have them loaded
standalone: you (i.e. the macro developer) need to mark JavaScript modules as safe to have them loaded
I’ll go for the second option for now, which will reduce but not eliminate the inconsistency.
unsafe, since this is a core CKEditor feature, so it can have unexpected side effects
but it’s as unsafe as it is for inline then since it’s using a div elements as you said and inline editing is also using CKEditor, no? I understand the argument for not trivial but not this one.
change the root editable for the standalone edit mode
I meant hacking into the Classic Editing mode of CKEditor (iframe-based) to use a nested DIV as root editable rather than the BODY element. This is unsafe, because for the Classic Editing mode of CKEditor the fact that the BODY is the root editable is kind of implied, i.e. what the code expects.
FTR, currently I can’t even mark the live data widget as safe for standalone WYSIWYG edit mode because the date and list (suggest) filters are injecting hidden elements at the end of the BODY. Unfortunately this is quite common, so there is a significant number of rendering macros that can’t be fully rendered in standalone WYSIWYG edit mode because of this…