Magicline displayed in non-editable widget

[Radoslav Petkov]

Magicline is showing in non-editable widget and inserts blank space. This issued should have been fixed in this ticket ​https://dev.ckeditor.com/ticket/10828 , but it seems that magicline is displayed inside non-editable parts.

[Jakub Ś]

There is something wrong here (or plugin code is invalid).

1. Use the attached plugin.
2. Clear editor contents and insert widget into editor.
3. Try hovering at the bottom of the widget (NOTE: there already is paragraph below the widget)

Result: magicline shows inside the widget.

4. Click on magic line to insert paragraph below it and try typing.

Result: new line is inserted into div and you can't type in it.

[Szymon Cofalik]

Widget template should not contain elements with contenteditable set to false. Clearing this attribute from code submited by j.swiderski resulted in correct behavior of magic line. In the gif provided by rpet I can also see nested contenteditable=false elements.

[Adrian Mitev]

Is there a workaround for that. Because I really have to use contenteditable="false" inside a widget.

[Piotrek Koszuliński]

A workaround would be to not use contenteditable=false inside editor, but only in the data. To do so you can add it when widget is downcasted and remove it when it's upcasted.

But I really don't understand why you need that attribute in your data. The widget isn't editable anyway, because that's widget's role to ensure that. It only breaks the editor and that's kind of a bug of course but I choose to not complicate editor even further, because this attribute should not be used inside widget in the first place.

[Adrian Mitev]

Because I have a requirement to have a fully workable input fields (inputs, radio buttons, selects) inside the editor (yes, I know that this is out of the WYSISWYG scope) and wrapping them contenteditable=false is the only way to make it work.

BTW I already asked for other ways to achieve this here - ​http://stackoverflow.com/questions/30054193/defining-black-box-zones-in-ckeditor

[Piotrek Koszuliński]

But it still does not make sense to me. Widgets use contenteditable=false. So this attribute is automatically added to widget wrapper by the widgets system.

If you want to have inputs inside widgets then you need to make sure that important events like mousedown and keydown which were fired inside this inputs does not reach editor's editable. Otherwise they will be handled by the editor and e.g. if you click an input its parent widget will be focused. To prevent this it should be enough to stop propagation of these events inside input elements.

[Adrian Mitev]

You're right. I'm using this approach (stoping event propagation) and it works well. However I am setting contenteditable="false" inside the widget because this fixes an issue on FireFox where the browser selects all of the text inside the widget when i just click on it. Idea how to workaround this (it appears only in FF) ?

[Piotrek Koszuliński]

Sorry, but now. It sounds like some of your modifications broke the feature where widget is being selected with a fake selection on click. Fake selection means that text of a widget will not be selected, but only the outline appears. Real selection is hidden in a invisible container. And it seems that this feature stopped working. Can't help with this.

[Adrian Mitev]

Okay. Thank you very much for the hints. I'll look for a way to deal with that.

[Adrian Mitev]

Please give me one more hint - if i put the event handlers that call stopPropagation() on the widget element, the FF problem still appears. Is the fake selection implemented using handlers on editor level or handlers on widget level?

[Piotrek Koszuliński]

Check this function: ​https://github.com/ckeditor/ckeditor-dev/blob/master/plugins/widget/plugin.js#L2293

Those listeners are added to document or editable (depends on editor type). So stopPropagation() on widget.element should be enough.

[Adrian Mitev]

I tried to put the event handlers that call stopPropagation() on the events on the .cke_widget_wrapper element. However this still breaks the fake selection on widget click and FF still selects all the text and the widget doesn't "gain" focus (the outline stays yellow, not blue). And by looking at the lines you provided, this is an expected behaviour, because I prevent the event to reach the editor's listeners. My current idea is to call widget.focus() in some particular situations instead of the editor's listeners (because the event doesn't reach them).