Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
The Table Element in the Wyswyg Text Editor is not usable, because its Table properties cannot be edited (don't get focus)
Steps to reproduce
Add a Paragraph Component with a Text Field with a Wysywyg Text Editor containing the Table element, and adding/editing this component just try to add and edit a Table component (@see the attached screenshot).
This doesn't happen with the same Wysywyg Text Editor not managed throughout the Layout Paragraphs Widget dialog ...
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | lp-table-element-not-usable_3196477_#11.patch | 1.06 KB | itamair |
| #4 | lp-table-element-not-usable.patch_3196477_#4.patch | 840 bytes | itamair |
| Screenshot 2021-02-04 at 09.53.30.png | 154.14 KB | itamair |
Comments
Comment #2
itamair commentedComment #3
dk-massive commentedCKeditor disables interactions with anything outside the current dialog. That unfortunately includes the new dialog window popping up with the table. This is a duplicate of this issue in core: https://www.drupal.org/project/drupal/issues/3065095#comment-13311079
Comment 17 solved this on my end. Their solution was to add that snippet Knaffles mentions with a module. I think they did not patch it in due to CKeditor/jquery.iu being a third party library and maintained outside of Drupal.
I went ahead and created a quick patch that adds this to Layout Paragraphs so you won't have to create a custom module to add the script.
Comment #4
itamair commentedthanks @dk-massive. I tested and reviewed it and your patch really fixes the issue.
I just amended with a comment to the added behaviour (so to make more clear what it does and what drupal issue is fixing),
and also changed its naming into a more appropriate drupal patches naming convention.
I mark this a RTBC ...
Comment #6
itamair commentedCommitted into dev ...
Comment #7
itamair commentedComment #9
donquixote commentedThe way that Drupal.behaviors is used here looks wrong.
Keep in mind that Drupal.behaviors is called again, each time a new element is added to the DOM tree!
Comment #10
itamair commentedhence, let's reopen this, for a better implementation.
Thanks @donquixote.
May you provide here a correcting patch?
Are you minding about this last Drupal.behaviors.allowChildDialogInteraction , or also the Drupal.behaviors.layoutParagraphsWidget?
I don't get if you wanna merge the Drupal.behaviors.allowChildDialogInteraction code into the Drupal.behaviors.layoutParagraphsWidget or provide it with a "once" or whatever? ...
Some further hints/suggestion may help this fix ... :-)
Comment #11
donquixote commentedI only had a superficial look at this, coming from another issue.
The main question is what should this code accomplish, and when do you want it to execute?
- One time on page load, OR
- Every time a new piece of html is added to the page?
Comment #12
itamair commentedYou are right, @donquixote ... we don't need the Drupal.behaviour here, as that code need to be loaded just on page load,
and it is working fine also with this new patch setup.
In fact all the solutions mentioned in this related core issue: https://www.drupal.org/project/drupal/issues/3065095 are not embedding that code in the Drupal.behaviour too.
Comment #14
itamair commented#12 Patch committed into dev, will be part of the next release.
Comment #15
itamair commented