Problem/Motivation
If the top offset of the page changes (e.g. the website has a header that changes size when scrolling), the sticky panel of the CKEditor5 does not register the change and gets stuck 'midair' because of the previous value.

Even if on scroll Drupal.displace() is called to correctly calculate the new value for the top offset, and the CKEditor instance value for ui.viewportOffset is updated, the StickyPanel class does not track this change (even though it is bound to this value).
Code in core/assets/vendor/ckeditor5/editor-classic/editor-classic.js that binds the value:
e.stickyPanel.bind("viewportTopOffset").to(this,"viewportOffset",(({top:e})=>e||0))
CKEditor is integrated with Drupal's displace api by updating the value of editor.ui.viewportOffset :
$(document).on(
`drupalViewportOffsetChange.ckeditor5.${id}`,
(event, offsets) => {
editor.ui.viewportOffset = offsets;
},
);
Steps to reproduce
- Create a page header with the 'data-offset-top' attribute;
- Update the height of the header (for example on scroll) and recalculate the top offset value with Drupal.displace();
- Focus on a CKEditor5 instance;
- Scroll down while maintaining the focus on editor and observe weird behaviour of the panel.
Proposed resolution
For whatever reason, creating a clone object of the displace offsets works properly:
$(document).on(
`drupalViewportOffsetChange.ckeditor5.${id}`,
(event, offsets) => {
editor.ui.viewportOffset = Object.assign({}, offsets);
},
);
I think this is because Drupal never changes the offsets object, just updates the values; so editor.ui.viewportOffset always references the same object and the StickyPanel bind does not trigger at all.
See the patch below.
Remaining tasks
-
User interface changes
-
Introduced terminology
-
API changes
-
Data model changes
-
Release notes snippet
-
| Comment | File | Size | Author |
|---|---|---|---|
| ckeditor5-sticky-panel-offset.patch | 700 bytes | rares badita | |
| Screenshot 2024-11-14 at 11.21.14.png | 40.06 KB | rares badita |
Issue fork drupal-3487446
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
quietone commentedChanges are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.
Also unassigning. For Drupal core, it is preferred that contributors add a comment that they are working on an issue instead of assigning it to themselves. See Assigning ownership of a Drupal core issue.
Comment #8
dydave commentedQuick follow-up on this issue:
As suggested at #3, created the new merge request MR !10183 for D11 above at #5.
I was brought to this issue from a related ticket for the Admin Toolbar module:
#3426402: zindex issue between admin toolbar and ckeditor 5
I have tested this locally with Admin Toolbar and couldn't really see a difference with or without the patch.
In other words, calling
Drupal.displace();(in the console) seems to have the same result in both cases: The CKEditor Toolbar seems to get the correct offset calculated.I have not tested with the steps suggested above in the IS, so I'm unable to really say whether this patch fixes the issue initially reported.
Setting this issue to Needs review anyway, as an attempt to get more reviews, comments or feedback.
Thanks in advance!
Comment #9
smustgrave commentedMaybe something we can get a test showing the problem