Unable to link text in rich text field using CKEditor 5 when adding a new Media entity via a Media field on a node.

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

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

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 🐛 CKEditor 5 balloons invisible when CKEditor 5 is used inside a modal Needs work works for me and typing is possible. This patch also solves the following issue for me: https://www.drupal.org/project/drupal/issues/3351603 🐛 CKEditor 5 link broken in Dialog if another CKEditor exists Needs work

Patch in #9 is working for us.

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

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

Latest MR is working for me.

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 here are broken in 10.3.0 and don't work with jQuery UI modals.

#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 custom property --ck-z-modal is no longer used in v10.3.0, nor does .ck-body-wrapper have a CSS stacking context due missing position: relative; or similar.

Also the jQuery UI modal receives an inline postion style top: ......px. So even if we set position and z-index, the balloon is still incorrectly positioned from top.

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

Using Drupal 10.3.1, I confirm @hudri at comment 28 🐛 CKEditor 5 balloons invisible when CKEditor 5 is used inside a modal Needs work :

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

scott_euser → changed the visibility of the branch 3328425-balloons-invisible-cke-in-modal-11x to hidden.

scott_euser → changed the visibility of the branch 3328425-unable-to-link to hidden.

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 🐛 CKEditor 5 balloons invisible when CKEditor 5 is used inside a modal Needs work 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: