Opened 9 years ago

Last modified 9 years ago

#12388 confirmed Bug

Conflict when system uses data-widget attributes for other purposes than the Widget system

Reported by: dan turcu Owned by:
Priority: Normal Milestone:
Component: UI : Widgets Version: 4.3
Keywords: Cc:

Description (last modified by Piotrek Koszuliński)

When I enter the source mode, and exit, all the buttons of the editor are disabled, for some contents.

See comment:5 for steps to reproduce.

Change History (7)

comment:1 Changed 9 years ago by dan turcu

I discovered the real problem. The buttons are disabled if the attribute data-widget="image" is present in a <a> tag. This attribute is used by mobile devices, to know that a link is pointing to an image.

comment:2 Changed 9 years ago by dan turcu

Also this problems appears only if the widget plugin is present in the editor.

comment:3 Changed 9 years ago by Jakub Ś

Status: newpending
Version: (GitHub - major)

Could you describe this problem in more detail?

If you go to and click inside a widget (best text under image2 widget) you will see that most buttons get disabled. This is correct behaviour as there are only certain elements that can be put into nested contenteditable.

comment:4 Changed 9 years ago by dan turcu

The issue , is that , if I have a tag in the source of the form : <a data-widget="image" href="some_link">some text</a> when you will enter the source mode and then you will exit to the source mode : you will get all the editor buttons disabled.

The steps to reproduce this problem are :

  1. Go to
  2. Enter source mode in the Enhanced Image and add this line anywhere in the source : <a data-widget="image" href="">some text</a>
  3. Exit the source mode and you'll see that all the editor buttons are now disabled

I know that the data-widget attribute is used internally by the editor but in our application we use this attribute to tell mobile device, that the link is pointing an image.

comment:5 Changed 9 years ago by Jakub Ś

Component: GeneralUI : Widgets
Description: modified (diff)
Status: pendingconfirmed
Version: 4.5.0 (GitHub - major)4.3

Steps to reproduce:

  1. Set config.allowedContent = true; for editor
  2. Load image2 sample
  3. Switch to source mode and paste <a data-widget="image" href="​">some text</a>
  4. Switch to WYSIWYG

Result: JS error is thrown (thus all buttons get disabled)

Message: Cannot read property 'getAttribute' of null
Line: 364
URI: ckeditor/plugins/image2/plugin.js

Problem can be reproduced from CKEditor 4.3

comment:6 Changed 9 years ago by Piotrek Koszuliński

Description: modified (diff)
Summary: All Editor buttons disabled after exiting the source modeConflict when system uses data-widget attributes for other purposes than the Widget system

I'm trying to figure out some workaround, but it is a tough problem. Widget system uses the data-widget attribute heavily and well... it should use data-cke-widget as in all other cases, but for some historical reasons we kept data-widget. Changing this decision now would be very risky, because we could break existing implementations, so I'm rather against this.

I was considering adding a configuration option which would stop widget system from upcasting elements based on data-widget attribute. It might be the best possible solution, but I'm not 100% certain about pasting. I think that in this case we first find wrapper (at least before 4.5.0) but it will need to be checked. In any case, this is not a solution that we'll quickly introduce.

Therefore, the workaround for now that I would propose would be to get rid of all data-widget attributes from data before loading it to editor. Something like:

editor.setData( myData.replace( /data-widget=/g, 'data-mypersonalwidget=' ) );

And the opposite when getting data. This will work perfectly fine unless you need data-widget attributes inside editor. But I think that it should not be a problem too.

comment:7 Changed 9 years ago by Piotrek Koszuliński

I was asked on other channel:

Why do we use data-widget instead of data-cke-widget?

It remained from the first stage of widgets implementation. We didn't implement upcasting and downcasting at that moment - this concept was born later. Instead, we were basing on data attributes which were outputted to data, so the name might not be data-cke-widget, because it's an internal name. Then, we added upcasting and I should have changed the name, but I lacked time. From today's perspective it's obvious that it was a mistake, but back then it of course wasn't so easy decision taking into account hundreds of already existing tests. And it's not only replace/data-widget/data-cke-widget/ - that wouldn't work. We would need to rewrite tests because data-cke-widget will not be outputted by data processor - it strips all data-cke* attributes.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy