Ckeditor4: Floating Inline Toolbar Does not Reposition on Scroll when contenteditable is Child of Scrolling div

[markdon]

Bug

Provide detailed reproduction steps (if any)

1. Open this JSFiddle: https://jsfiddle.net/L5ax0qqs/
2. Click inside the contenteditable div.
3. Scroll down.

Expected result

Floating inline editor toolbar follows editable content until it is not visible on the page.

Actual result

Floating inline editor toolbar does not follow editable content.

Other details

• Browser: Chrome
• OS: Windows 10
• CKEditor version: 4.7.3
• Installed CKEditor plugins: standard

Looking at the Floating Space source, I can't find a good way to trigger the layout function from my code. Figuring this out might help with a workaround.

[markdon]

Investigating this further today. I've found that since Floating Space listens to window for scroll events and scroll events do not bubble up to the window the layout function won't trigger. One way around this would be to use capture events with the listener. e.g. replace this line with

window.addEventListener('scroll', uiBuffer.input, true);

^(IE9+ only)

Another way would be to listen for scroll on the div and trigger it on the window. This can be done in your own code with:

document.getElementById('scrollable').addEventListener('scroll', function(){
    CKEDITOR.document.getWindow().fire('scroll');
});

I find this doesn't update frequently enough and gives janky results.
Here's a demo

Even when the layout is updating on scroll the behaviour is not ideal. I would expect that the toolbar would be inside the div and would disappear as the content scrolls out of view. To achieve this I think the toolbar dom element would need to be a child of the scrolling div, not the body and the layout function would have to do calculations based on the scrolling div view, not the window view.

[mlewand]

This is actually a feature request, that enhances the inline toolbar.

First of all thanks for the investigation placed already into this issue!

As you noted, adding this feature requires several other enhancements to be implemented to make this feature feel right.

Surely we can't put the toolbar in the editable element, most of plugins assume that there's as little UI/decoration markup as possible. What we could to is to make the toolbar aware of host scrolling, and allow it to reposition within a certain limit box (viewport for instance).

Also another solution would be to the Balloon Toolbar.

Changing the issue type.

[markdon]

Thanks for looking at this again. This hasn't created any actual problem for me after implementing my workaround. It's not likely many of our users have noticed since we're hiding the toolbar behind a toggle and I assume most of our users using rich text are pasting from word.

[adamgruber]

Ran into this same issue. For now I've implemented the solution suggested by @markdon where I'm just listening for scroll events on my container and subsequently triggering them on window. While this works, it's definitely not ideal as the scroll update isn't very smooth.

Just curious if there are any other workarounds that might offer a better user experience?

[amcsi]

There's also a bug report for this in the CKEditor issue tracker: https://dev.ckeditor.com/ticket/14608