Issue with z-index when opening in modal dialog

Created on 1 May 2021, about 3 years ago
Updated 14 May 2024, about 1 month ago

Problem/Motivation

I noticed a z-index issue when using the "Insert from Media Library" from within CKEditor.
After adding a new Media document, the fields that use the select2 widget are not working properly because the select2 z-index is lower than the dialog's z-index.

The dialog in this case will have a z-index of 10001.
See ckeditor.js:155, where CKEDITOR.config.baseFloatZIndex has a default value of 10000

$(window).on('dialogcreate', function (e, dialog, $element, settings) {
  $('.ui-dialog--narrow').css('zIndex', CKEDITOR.config.baseFloatZIndex + 1);
});

Steps to reproduce

- Create or update a media type and use a select2 field widget for one of the fields
- Setup the Media Library button with CKEditor
- Click on the "Insert from Media Library" CKEditor button
- Add a document
- > The field that uses select2 is not working properly

Proposed resolution

This issue was also encountered in select2_all module: #3091977: Fix compatibility with jQuery UI modal zindex β†’

As mentioned by Dave there,
1. The quick fix is to simply increase the z-index to CKEDITOR.config.baseFloatZIndex + 2 = 10002.
2. The proper way to fix this would be to use dropdownParent.

Remaining tasks

?

User interface changes

?

API changes

?

Data model changes

?

πŸ› Bug report
Status

Postponed: needs info

Version

1.0

Component

Field widgets

Created by

πŸ‡§πŸ‡ͺBelgium herved

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Status changed to RTBC about 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States jasonmce Washington, DC

    #17 Fixed the issue I was having. No regression issues found in small positive manual test.

  • πŸ‡«πŸ‡·France bakop Lille

    Hi, tested patch #17 on a Drupal 9.5.9 and it works.
    RTBC +1

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    Confirmed, #17 fixes the issue for me too, here on Drupal 10.1

  • πŸ‡§πŸ‡ͺBelgium herved

    Same here on D10.1 with #17, thanks! +1

  • πŸ‡§πŸ‡ͺBelgium herved
    +++ b/src/Element/Select2.php
    @@ -209,7 +210,11 @@ class Select2 extends Select {
    +      $element['#prefix'] = '<div id="' . $wrapper_id . '">';
    +      $element['#suffix'] = '</div>';
    

    Update: I haven't really checked in depth but why do we need a wrapper div here?
    This would need a change record or similar as it can break existing styling in some cases.

  • πŸ‡ΊπŸ‡ΈUnited States DaleTrexel Minnesota, USA

    One more success with #17, Drupal 10.1.8, PHP 8.2. Thanks for the work on this!

    @herved the patch does not work without the #prefix/#suffix wrapper because the ID is key for the dropdownParent property to have a unique ID to work with/reference. If $wrapper_id isn't added as an ID here, then you'd need to add the ID to some other element wrapper around the field, but within the modal.

  • πŸ‡ΊπŸ‡ΈUnited States DaleTrexel Minnesota, USA

    I should add that I have just found some cases where this patch does break styling of some Select2 elements on the site I applied it to, so a change record/notice is definitely important if you stick with the current solution. If you can place the ID used by dropdownParent in some other pre-existing wrapper, that would have less impact.

  • πŸ‡ΊπŸ‡ΈUnited States DaleTrexel Minnesota, USA

    Is there a way we can determine when the wrapper is actually needed in the Select2 class, vs. simply setting the dropdownParent to the form ID (without adding any wrapper), as was the approach at the start?

    After further review of the impacts throughout our site, I've found that the wrapper is not actually needed for any of our Select2 fields, but when present it DOES cause significant styling issues in some cases.

    I think it would be well worth figuring out how to be more selective about the inclusion of the wrapper, to minimize impact to users of this module. I'd take a stab at it myself, but I don't have any use cases that actually need it, so it's hard for me to know where to begin and how to test.

  • Status changed to Needs review 3 months ago
  • πŸ‡¨πŸ‡¦Canada tame4tex

    Could the issue be more easily solved in JS by determining if the element is in a modal and then getting the parent form object to set as the `dropdownParent `?

    The attached patch is working for me in paragraphs, modals and regular forms without the need for a new wrapper element.

  • Status changed to Postponed: needs info about 2 months ago
  • πŸ‡©πŸ‡ͺGermany chr.fritsch πŸ‡©πŸ‡ͺπŸ‡ͺπŸ‡ΊπŸŒ

    Is this still an issue?
    Because for me it seems to work.

  • πŸ‡¨πŸ‡¦Canada endless_wander

    Patch #25 did not work for me using Layout Paragraphs where a field within a Paragraph has Select 2 enabled for form display.

    Patch from #17 works in this scenario for me.

Production build 0.69.0 2024