CKEditor 5 balloons invisible when CKEditor 5 is used inside a modal

Are there browser console errors?

Verified that the problem exists. Bumping this to Major.

Got the following error in the JS console (not sure its related)

Uncaught TypeError: Cannot read properties of undefined (reading 'settings')
    at HTMLDocument.resetSize (dialog.position.js?v=10.1.0-dev:82:32)
    at later (debounce.js?v=10.1.0-dev:37:23)

Did more debugging on this. TL;DR, it's a z-index issue. Updating issue summary.

More digging. This was originally fixed in #3274937: Get CKEditor 5 to work in (modal) dialogs. Somehow it regressed.

So the problem is that the fix in #3274937: Get CKEditor 5 to work in (modal) dialogs assumed that the .ui-dialog div willalways occur before the .ck-body-wrapper in the DOM. This isn't always the case, which leads to this issue.

The fix for this is to either globally raise the z-index to 1261 or, we need to have a jQueryUI add a CSS class to the body element so we can use that in our selector.

Talked with @lauriii on a minisprint today, and he agreed changing the global value of the CKEditor balloon to 1261 is the path forward.

Here's some initial work on changing the global value, however, it's not quite ready.

An issue can up during testing where if you have a CKEditor instance not in a modal, and then trigger a balloon panel (which is the correct terminology I learned), and then you open up a modal, the balloon panel will still be visible.

We should close all balloon panels on focusout IMHO. I'm not too familiar with CK5's internals so not quite sure how to proceed.

Hi, I'm also experiencing this bug with paragraphs popup: the "add link" z-index needs to be greater than 1260.

Modern CSS can easily query forwards and backwards. When the initial, unobtrusive solution was

.ui-dialog ~ .ck-body-wrapper {
    --ck-z-modal: 1261;
}

than the opposite direction is also possible, with exaclty the same CSS specifity

.ui-dialog ~ .ck-body-wrapper, .ck-body-wrapper:is(:has(~ .ui-dialog)) {
    --ck-z-modal: 1261;
}

(The :is is not strictly necessary, but it turns the 2nd half of the selector into a "forgiving" selector that doesn't kill the entire rule if a browser does not support :has yet)

All relevant browsers except Firefox support :has, and Firefox should support it within first half of 2023

PS: My merge request still suffers from the problem that @mherchel mentioned in #9

I want to add that I'm facing this issue as well in another scenario.

I'm trying do add a link to a CKEditor that is inside a Layout Builder Modal

Clarifying issue title.

The patch in #9 works and displays the pop-up, but it does not allow typing in the input box.

I could type in the input box fine testing this out, perhaps you could provide steps to reproduce that @abhisekmazumdar?

@mherchel for #9 I could not reproduce in my scenario but perhaps could consider applying the z-index within :focus-within in some way here rather than a likely complicated CKE5/JS solution?

I can confirm the patch in #9 works for me and typing is possible. This patch also solves the following issue for me: https://www.drupal.org/project/drupal/issues/3351603

Patch in #9 is working for us.

MR !4288 introduced in #16 works. Thank you very much. Didn't try #9.

Patch #16 works for me. Now the link pop-up is showing over a modal layout paragraph.

Latest MR is working for me.

Edit: Scratch that...this patch appears to break in layout builder now. Before this patch, I was seeing no issues with these dialogs in layout builder.

Hi, after updating to Drupal 10.3, the CkEditor inside Layout Builder iFrame Modal works fine and I don't need anymore this patch.

Re-roll of the MR fix against 10.3.x.

All patches and MR do no longer work in v10.3.0

#26 seems not relevant to this issue due I-Frame. The issue here is about CKeditor ballons in Ajax modals inside a simple < div >.

#27 does not work, the property --ck-z-modal is no longer used in v10.3.0. The relevant property was renamed to --ck-z-panel

Patch from #27 applies clean for me, Drupal 10.3.0.

Using Drupal 10.3.1, I confirm @hudri at comment 28:

#27 does not work, the property --ck-z-modal is no longer used in v10.3.0. The relevant property was renamed to --ck-z-panel

So patch#27 updated to use --ck-z-panel (instead of --ck-z-modal or using both for retrocompatibility) will be OK.

The current approach in the MR also does not work; it assumes we are in Claro, but for example even the test in core/modules/ckeditor5/tests/src/FunctionalJavascript/CKEditor5DialogTest.php is using Olivero, so the issue recurs.

At that same automated test URL you can also see other variables used as well, like panel, not just modal, and having the same issue. Screenshot once updated MR is applied:

Attempted to add test coverage to core/modules/ckeditor5/tests/src/FunctionalJavascript/CKEditor5DialogTest.php after the $this->pressEditorButton('Link'); but does not seem like either of these are true tests for visibility unfortunately:

$assert_session->waitForElementVisible('css', '.ck-balloon-panel');
$assert_session->assertVisibleInViewport('css', '.ck-balloon-panel');

Would be good to get a review on that + advice whether true visibility/z-index is testable within what we have available in Drupal.

This is by the way still an issue in 11.x and easily reproduced by:

1. Install ckeditor_test test module
2. Go to /ckeditor5_test/dialog
3. Click add node
4. Click on the link toolbar icon

Updated issue summary to standard template.

Okay actually has to be 1262 (1 higher) otherwise balloon within modal within modal does not work. Tested this by:

1. Enable footnotes module 4x branch
2. Add footnotes to toolbar
3. Install ckeditor_test test module
4. Go to /ckeditor5_test/dialog
5. Click add node
6. Click footnotes icon to load modal within modal
7. Click on the link toolbar icon

This is the same approach used by 'ai' module + 'ckeditor5_embedded_content' module, and I would guess others as well. I expect you could reproduce with Core alone by adding a cke5 formatted text field to a media entity then loading that within media insert of e.g. article body field.

Did some tidy up of branches/patches. If anyone needs patch, please follow the documentation to download a patch locally. You can also use the 'show' buttons to show links just for yourself to old patch files, but please don't post new ones. Thanks!

Screenshot of balloon within modal within modal:

For those commenters that couldn't click in the input box after applying the patch, the toolbar might be at fault. My particular issue is after I open a modal from the toolbar. If I close the modal and reload the page, the input field works fine. (I'm using a custom module called account modal that opens the user/edit in a modal, including the link in the toolbar user menu.)

Could you make a screencast of that perhaps? Maybe unrelated but good to understand the issue better; I guess if it can't be focused perhaps something else is in the way or maybe some other js overriding focus

"So patch#27 updated to use --ck-z-panel (instead of --ck-z-modal or using both for retrocompatibility) will be OK."

Confirming --ck-z-panel works in 10.3.1

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Hiding patch. Please download patches locally instead as per documentation. Helps avoid confusion + things like the above with the bot reviewing the patch instead of the merge request.

The patch in #44 works for me in Drupal 10.3.1 with Layout Paragraphs.

patch unexpectedly ends in middle of line
Hunk #1 succeeded at 9 with fuzz 1.

Looking at remaining tasks looks like the open one is to get maintainer approval.

Elevating

Here's the patch for drupal core 10.3.5 which we're using on one of our website

I just want to add a comment in here for anyone still dealing with CKeditor 4 and seeing this issue that may need a fix sooner than moving to CKeditor 5 and applying this patch (nevertheless, you should really be using CKeditor 5 and indeed I will look to get the project I'm working on to move to this)

It appears CKeditor 4 doesn't have the ui-dialog class at all, this seems pretty essential to make things work (nevermind if you then see the issues mentioned above)

In my case, i found simply adding `ui-dialog` as a class to the div that also has `cke_reset_all cke_dialog_container` classes already, made all functionality click into gear and work as expected.

I have a custom admin subtheme theme added to the project, i did a pre-process hook in the .theme file to add a library on the relevant content type node-edit pages

function MY_THEME_form_alter(&$form, &$form_state, $form_id) {
  if($form_id == 'node_layout_page_edit_form'){
       $form['#attached']['library'][] = 'MY_THEME/ckEditorInteractivity';
    }
  }

And then wrote JS similar to this (couldn't see a way to add the class via patch or similar).

/**
 * @file
 * MY THEME behaviors.
 */
(function (Drupal) {

  'use strict';

  Drupal.behaviors.myTheme = {
    attach (context, settings) {
      /** TEMPORARY JS (until CKEditor5 is implemented) that only runs on layout page nodes.
       * This ensures that ckEditor modals are clickable and can be interacted with on layout page nodes.
       * This will observe the DOM and add a class to the CKEditor dialog window once the editor window
       * itself is added to the DOM. */
      const observer = new MutationObserver(function(mutations) {
        mutations.forEach(function(mutation) {
            if (mutation.addedNodes && mutation.addedNodes.length > 0) {
                // element added to DOM
                let hasClass = [].some.call(mutation.addedNodes, function(el) {
                    return el.classList.contains('cke_dialog_container');
                });
                if (hasClass) {
                  let ckEditorDialogueWindows = document.getElementsByClassName("cke_dialog_container");
                  for (const window of ckEditorDialogueWindows) {
                    window.classList.add('ui-dialog');
                  };

                }
            }
        });
    });

    var config = {
        attributes: true,
        childList: true,
        characterData: true
    };

    observer.observe(document.body, config);
    }
  };

} (Drupal));

This JS observes the page and once CKeditor inserts its dialog divs, it adds the 'ui-dialog' class

Of course, don't forget to add the JS file reference in your subtheme libraries file

ckEditorInteractivity:
  js:
    js/ckEditorAddDialogClass.js: {}

MR of upping the z-index seems pretty straight forward. Going to mark to get in front of framework managers.

I've added some comments to address on the MR.

Thanks for the feedback. I applied the comments and retested as per #40 and all works fine. Changing to 9999 for the line suggested to match the cke5 dll doesn't hurt of course.

Merge conflicts, needs update

1. Merged 11.x into the branch
2. Retested with Footnotes module (disabling the fix that the module itself is applying)
3. Balloon within modal appears again:

Going to go on a limb and leaning on testing in #56 that feedback has been addressed

Given that this was a regression and the actual implementation had to change based on CKE evolution, this needs a proper test to make sure the fix works after a CKE update

I couldn't see how we can add test coverage as per my comment in #35 - could use a pointer in the right direction. For convenience:

Attempted to add test coverage to core/modules/ckeditor5/tests/src/FunctionalJavascript/CKEditor5DialogTest.php after the $this->pressEditorButton('Link'); but does not seem like either of these are true tests for visibility unfortunately:

$assert_session->waitForElementVisible('css', '.ck-balloon-panel');
$assert_session->assertVisibleInViewport('css', '.ck-balloon-panel');

Would be good to get a review on that + advice whether t

Here's the patch for drupal core 10.4.6 which we're using on one of our website

Feels like no patching is needed with Drupal 11.3.2 (it may have fixed in earlier release but I've only checked using this one).