Widget with complex structure allow editing of widgets' editables (if those are divs)

[Matti Järvinen]

If widget editables are not direct descendants of widget root element, it is possible to edit/delete elements' editables with CreateDiv context menu options. Deleting results in loss of editable element and its content is moved into editables parent element.

In example below with CreateDiv context menu you could remove content-left and content-right columns. Moving content from those divs to their parent divs (col-xs-12).

Juicy parts of an widget definition:

allowedContent: 'div(!row);'+
            'div(!col-xs-12,col-sm-6,col-sm-3,col-sm-9);'+
            'div(!content-text,content-left,content-right);',

// Minimum HTML which is required by this widget to work.
requiredContent: 'div(!row);div(!col-xs-12);div(!content-left);div(!content-right);',


// Define two nested editable areas.
editables: {												
            contentLeft: {
              selector: '.content-left'
            },
            contentRight: {
              selector: '.content-right'
            }
},
// Define the template of a new widget.
template: '<div class="row">' +					
            '<div class="col-xs-12 col-sm-6">' +
              '<div class="content-text content-left">' +
                '<h2>Title 1</h2>' + 
                '<p>Some text</p>' +						
              '</div>' +
            '</div>' +
            '<div class="col-xs-12 col-sm-6">' +
              '<div class="content-text content-right">' +
                '<h2>Title 2</h2>' + 
                '<p>Some text</p>' +						
              '</div>' +
            '</div>' +					
          '</div>',

[jhub]

I encountered this bug too (in 4.4.5). This is easy to reproduce even with the simplebox sample widget, if the editor also has the "div" plugin active. Click the toolbar button for the simplebox to create one, then in the document, right-click on the "Content..." part of the simplebox. The context menu contains "Edit Div" and "Remove Div", which it shouldn't.

I implemented the following fix for myself.

In /ckeditor/plugins/div/plugins.js, the if-condition on line 103:

Original:

if ( CKEDITOR.plugins.div.getSurroundDiv( editor ) ) {
    ...
}

My change:

var surroundDiv = CKEDITOR.plugins.div.getSurroundDiv(editor);
if ( surroundDiv && !surroundDiv.hasClass("cke_widget_editable") ) {
    ...
}

[Marek Lewandowski]

Alright so basically what you see here is a missing integration between div and widget plugins. The problem is that with allowing div element in ACF (allowedContent property) you'll enable div plugin. The div looks for closest div element (no matter what) and... finds it, that's editable wrapper.

Both of you guys did the same but in a slightly different way.

What we need here is either:

• a simple solution that div plugin will stop traversing parents once it stumbles upon .cke_widget_editable element,
• or we can provide more sophisticated function that will return all the parents that are editable (isContentEditable===true) with the exclusion of the element that specifies contenteditable="true", because that would be the editable wrapper itself.

Note that this issue is not limited to divs, see #12611.

[Marek Lewandowski]

Don't forget to ask @Reinmar for opinion.

[Jakub Ś]

I have prepared samples for both of these widgets and confirm that this problem can be reproduced from CKEditor 4.3 in all browsers.