Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#13335 closed Bug (invalid)

Magicline displayed in non-editable widget

Reported by: Radoslav Petkov Owned by: Szymon Cofalik
Priority: Normal Milestone:
Component: UI : Widgets Version: 4.5.0 Beta
Keywords: Cc:

Description

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.

Attachments (3)

magiclineContentEditableFalse.gif (848.9 KB) - added by Radoslav Petkov 4 years ago.
2015-05-29_1526.swf (974.3 KB) - added by Jakub Ś 4 years ago.
mywidget3.zip (737 bytes) - added by Jakub Ś 4 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 4 years ago by Radoslav Petkov

Summary: Integrate magicline with widgetsMagicline displayed in non-editable widget

Changed 4 years ago by Radoslav Petkov

Changed 4 years ago by Jakub Ś

Attachment: 2015-05-29_1526.swf added

comment:2 Changed 4 years ago by Jakub Ś

Keywords: show magicline in non-editable removed
Status: newconfirmed

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.

  1. 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.

Changed 4 years ago by Jakub Ś

Attachment: mywidget3.zip added

comment:3 Changed 4 years ago by Szymon Cofalik

Owner: set to Szymon Cofalik
Status: confirmedassigned

comment:4 Changed 4 years ago by Szymon Cofalik

Resolution: invalid
Status: assignedclosed

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.

comment:5 Changed 4 years ago by Adrian Mitev

Is there a workaround for that? Because I really have to use contenteditable="false" inside a widget in order to make input fields workable.

Last edited 4 years ago by Adrian Mitev (previous) (diff)

comment:6 Changed 4 years ago by 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.

comment:7 Changed 4 years ago by 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

Last edited 4 years ago by Adrian Mitev (previous) (diff)

comment:8 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by 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) ?

Last edited 4 years ago by Adrian Mitev (previous) (diff)

comment:10 Changed 4 years ago by 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.

comment:11 Changed 4 years ago by Adrian Mitev

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

comment:12 Changed 4 years ago by 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?

comment:13 Changed 4 years ago by 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.

comment:14 Changed 4 years ago by 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).

Last edited 4 years ago by Adrian Mitev (previous) (diff)
Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy