[upstream] CKEditor 5 language selector cannot be scrolled if "All NNN languages" option selected

Thanks for reporting this!

But … this is a duplicate of an issue that is 95% done, can you help get it to 100%? 😊

Transferring issue credit! 👍

I think there's a really good suggestion proposed in this issue. (I hadn't seen this issue, but I arrived at considering something like this while working on #3273986: Third option for the CKEditor 5 "Language" button: `site_configured` (in addition to `un` and `all`) recently.)

In #3273986: Third option for the CKEditor 5 "Language" button: `site_configured` (in addition to `un` and `all`) we let the user select "Site configured languages" to show the list of Languages configured at /admin/config/regional/language. That makes sense for a site which uses the same languages to translate nodes as it needs to select as Language of Parts elements in content, but the two don't necessarily equate.

Here in the ID @jonathan_hunt I believe is suggesting a configurable list of languages for use, managed I think from the CKEditor plugin configuration in the input format - for some sites I do think this might make sense. I can imagine a site offering nodes translated in one of two official languages of that country and then desiring to mark content sections in other local languages of that region.

I expect many sites might want the option to share the list of languages between input formats as well, to reduce double-handling ... I'm not sure it exactly fits being attached to the input format.

I'd say this issue is still valid as the dropdown menu is still very user unfriendly, when scrolling the languages.

Agreed, re-titling to focus on the specific scrolling issue & moving back to NW.

I suppose there could also be a search filter at the top of the list, which is friendlier than scrolling. An editor could start typing the desired language name into that field and only the matches would show, likely to be a short list. That said, it depends on how the languages are displayed. If they are displayed in their native name rather than the website administration language, typing the name could be an issue, for example, if the editor is trying to retrieve traditional Chinese but can only type in Latin characters.

@Charles Belov that's an alternative approach to the one proposed in the issue description (which is fine to suggest). It looks to me like that drop down interface element is provided by CKEditor, so might be worth thinking about whether CK offers such a filterable dropdown element to use.

From within Drupal, we can readily do things such as limit available options (as proposed in ID).

Fixing scrolling behaviour or providing a different UX may require proposing changes upstream in CK.

Thanks for re-scoping & re-titling! 👍

However, in this case … there's indeed nothing to fix on the Drupal side — it can only be fixed upstream. Can you please create an upstream bug report? 🙏

I found a fix that makes us less dependent from the cke community providing a fix: CSS, hooray :-)

.ck-dropdown__panel.ck-dropdown__panel-visible {
  overflow: scroll;
  max-height: var(--ck-min-height);
}

This is the result of a browser mockup based on Claro. Might need a higher specificity.

The custom property ck-min-height is (obviously) the minimum height of the textarea. Using this as the max-height of the dropdown works proportinal to the container size and still leaves a little space at the bottom so that the nature of the dropdown can be clearly distinguished.

I opened an upstream issue: https://github.com/ckeditor/ckeditor5/issues/15715

The suggested fix inspired by #11 could be added to our admin theme CSS as a workaround.

.ck-text-fragment-language-dropdown .ck-dropdown__panel {
  overflow-x: auto;
  max-height: var(--ck-dialog-max-height);
}

FYI upstream issue was closed as duplicate of https://github.com/ckeditor/ckeditor5/issues/952