Ensure that CKEditor 5 toolbar always remains visible in dialog *and* renders below dialog title bar (if it exists)

Created on 27 September 2022, about 2 years ago
Updated 24 January 2024, 11 months ago

Problem/Motivation

When scrolling inside a Drupal modal, the toolbar doesnโ€™t stay fixed at the top as itโ€™s not hitting the window limit but the modal limit.

Steps to reproduce

This can be reproduced using Drupal 9.4.6, 9.5.x or 10.0.0 by

  1. installing the ckeditor5_test module (included with core, used for tests โ€” requires $settings['extension_discovery_scan_tests'] = TRUE;)
  2. navigating to /ckeditor5_test/dialog (to avoid using a contrib module like @Nowrie's original report did)
  3. typing something very long in the CKEditor 5 instance
  4. scrolling down

Alternatively, this can be reproduced using contributed modules such as this example by @Nowrie: https://www.drupal.org/files/issues/2022-09-27/Screen%20Recording%202022... โ†’ โ€” see the original issue summary for the details on that.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

๐Ÿ› Bug report
Status

Closed: outdated

Version

10.0 โœจ

Component
CKEditor 5ย  โ†’

Last updated 2 days ago

Created by

๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom Nowrie

Live updates comments and jobs are added and updated live.
  • Contributed project blocker

    It denotes an issue that prevents porting of a contributed project to the stable version of Drupal due to missing APIs, regressions, and so on.

  • Needs frontend framework manager review

    Used to alert the fron-tend framework manager core committer(s) that a front-end focused issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

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.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States Greg Boggs Portland Oregon

    Anyone have any ideas on this one yet? The bar is super unpredictable if you click around in and out of the editor in certain ways, the box appears.

  • Status changed to Needs review over 1 year ago
  • last update over 1 year ago
    Custom Commands Failed
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States tim bozeman

    Yeah that is some odd behavior.

    I guess the behavior makes sense after reading _checkIfShouldBeSticky(). The editor needs focus, be scrolled beyond the view port, and the gotcha is that that calculation is triggered by the window scroll bar, not the dialog scroll bar.

    I took a hard look at adding dialog support to StickyPanelView, but it seems tricky. The editor hasn't been attached when StickyPanelView runs. The text area is scrollable initially and once the editor is attached it makes the dialog scrollable. It's also weird trying to loop through the parents to determine if it's inside a scrollable div.

    Can we just add our dialog support to the ckeditor5 module?

  • last update over 1 year ago
    28,526 pass
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States tim bozeman

    Custom commands...

  • Status changed to Needs work over 1 year ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bnjmnm Ann Arbor, MI

    I think this can be accomplished with just CSS. For example, this takes care of it in Claro:

    .ui-dialog .ck-editor__top {
      position: sticky;
      top: -1rem;
    }

    I haven't checked other themes, but there's a chance the top: will need to be different as it will look best if it matches the padding of the dialog content area.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States tim bozeman

    I think it would be an odd behavior to ignore the dialog scrollbar and only use the window scrollbar.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bnjmnm Ann Arbor, MI

    I'm not sure if #12 is a response to my proposed CSS solution, but it doesn't result in any ignoring of the dialog scrollbar.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States tim bozeman

    Oh, well dang. Huhโ€ฆ

    ยฏ\_(ใƒ„)_/ยฏ

    Nice!

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States Greg Boggs Portland Oregon

    love this

  • ๐Ÿ‡ง๐Ÿ‡ชBelgium wim leers Ghent ๐Ÿ‡ง๐Ÿ‡ช๐Ÿ‡ช๐Ÿ‡บ

    So โ€ฆ can we get #11 in patch form so I can RTBC this so a frontend framework manager can verify this?

    IMHO test coverage is overkill when no logic is changed and 2 lines of declarative code (aka CSS) are added ๐Ÿ‘ So removing the tag that I added in #2.

  • Status changed to Needs review over 1 year ago
  • last update over 1 year ago
    28,526 pass
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States tim bozeman

    Sure thing. Thank you @bnjmnm! ๐Ÿš€

  • Status changed to Needs work over 1 year ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States tim bozeman


    oh hmm, actually something funky's going on with the focus now. Also, when did the editor area get its own scrollbar? That seems like a different approach to solve this too. Maybe we should not do a sticky toolbar at all and put a min-height on the editor area?

  • ๐Ÿ‡ง๐Ÿ‡ทBrazil mabho Rio de Janeiro, RJ

    @Tim,

    I have also experienced the issue with the focus within a Layout Builder modal.

    It happens exactly as in your GIF sample.

    The issue seems to be triggered because of the element with class `.ck-sticky-panel__content` that gets a new class `.ck-sticky-panel__content_sticky` when you focus on editor.

    The problem is class `.ck-sticky-panel__content_sticky` carries `position: fixed; top: 0;`.

    My quick solution for this is, on top of Greg's solution, applying this thing:

    .ck-sticky-panel__content_sticky {
      position: absolute;
    }
    
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States tim bozeman

    It looks like it's just being addressed upstream. ๐Ÿคž๐Ÿผ

  • Status changed to Closed: outdated 11 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States tim bozeman

    It looks like it's been addressed upstream and has made its way into core.

Production build 0.71.5 2024