Widget > widget support?

[Reinmar]

An interesting use case that I've seen recently was using one widget nested directly in another widget (without nested editable).

We've been always thinking about widget > nestedEditable > widget scenarios. Images inside table cells are such a case. Placeholders inside image captions are another.

However, the way how we designed the widget API doesn't require the use of nested editables. Additionally, the model is separated from the view and the model doesn't even know that in the view the selection would end up directly in a non-editable part:

<widget>
    [<widget></widget>]
</widget>

The model doesn't actually know the concept of "nested editables" so such a selection, as long as widget is marked as isObject in the schema, is (to my knowledge) correct.

Now, what's the use case? Imagine you want to have a gallery with images. You build such a model:

<gallery>
    <image></image>
    <image></image>
    <image></image>
</gallery>

And, when converting this to the view you container representing the <gallery> a widget because you don't want to allow typing in it. You want to control its editing. But then, images are widgets too. Each of these images should be selectable by click. And that's exactly the bit that doesn't work now – the selection is extended to contain the <gallery> element.

I wonder, would be it possible to fix? Is this behaviour caused by the selection post-fixer? Or is it caused by incorrect mousedown handler in the Widget plugin?

BTW, from the selection perspective, this case seems quite similar to:

<table>
  <tr>
     [<td>1</td>]
     [<td>2</td>]
  </tr>
</table>

So, I think we could make these things work together, without affecting the selection post-fixer.

cc @jodator

[jodator]

@Reinmar AFAIR I've introduced some fixes to such scenario while working on table cell selection. So doing https://github.com/ckeditor/ckeditor5-table/issues/63. I'd had to dig up needed changes in the engine (selection post fixer mostly).

[Reinmar]

Test code:

function MyPlugin( editor ) {
	editor.model.schema.register( 'div', {
		allowIn: [ '$root', 'div' ],
		isObject: true
	} );

	editor.model.schema.extend( '$text', {
		allowIn: 'div'
	} );

	editor.conversion.for( 'downcast' ).add( downcastElementToElement( {
		model: 'div',
		view: ( modelElement, writer ) => {
			return toWidget( writer.createContainerElement( 'div', { class: 'widget' } ), writer );
		}
	} ) );

	editor.conversion.for( 'upcast' ).add( upcastElementToElement( {
		model: 'div',
		view: 'div'
	} ) );
}

Behavior:

It seems like the selection in the model is set correctly. So it seems that the highlight conversion marks the wrong elements. Interesting...

[Reinmar]

So it seems that the highlight conversion marks the wrong elements. Interesting...

Nope. I forgot that the base widget selection is handled by a normal selection converter, not the highlights system.

[Reinmar]

OK, the mistake is here:

https://github.com/ckeditor/ckeditor5-widget/blob/49afa6e3216334b18573ae0be42d6abb2af324cb/src/widget.js#L67-L81

We need to skip children of all widgets that we just marked.

[Reinmar]

I reported a ticket for the above issue: https://github.com/ckeditor/ckeditor5-widget/issues/57.

[Reinmar]

OK, it seems that https://github.com/ckeditor/ckeditor5-widget/issues/57 was the only bug that we found. So, it seems that widget>widget scenarios are supported.

[Reinmar]

And we found another one: https://github.com/ckeditor/ckeditor5-engine/issues/1593 :D